What you are asking for is not possible with an unmodified version of bitcoind. So I will interpret your question as why not and how to achieve something similar.
Having bitcoin nodes that do not relay transactions is a danger to bitcoin: If nodes start behaving that way, not only do we move a tiny step further towards risking that transactions are stuck because someone sending a transaction does not get them forwarded at all, but more importantly, mining exploits like the one described in the preprint Majority is not enough: Bitcoin Mining is Vulnerable move from the rather theoretical to the practical. In fact, someone trying to implement this exploit might ask pretty much the same question as you do!
So what stops you from just doing it anyways, with a modified version of bitcoind? Nothing, really, except that it seems a bit self-defeating. Consider that as soon as others start perceiving it as a sufficient nuissance (and they should, for reasons of fairness and security!), we'll come up with some modification that will require you to forward at least some transactions or not get transactions forwarded yourself. Or get stuck with only similarly selfish nodes to connect to. That'll be the exact opposite of what you want to achieve for verifying transactions. Just consider that eventually you may only see those transactions more likely to not get propagated all the way to the mining pools!
So what options do you have to limit bandwidth (I doubt you can save much CPU time, anyways)? Here are your options:
You already know the most radical answer: Not running your own copy of bitcoind, and instead use the public APIs of blockchain.info and blockexplorer.com (or some commercial solution). I presume you are not happy with relying on free external services, but considering that there is redundancy (to either deal with individual downtime or to get more than one confirmation). So this super-low bandwidth approach (at least for few transactions to actively monitor) may not be quite as bad as it must sound at first.
Limit the number of nodes your bitcoind connects to. This, unfortunately, is a double-edged sword. It simultaneously limits the data you will send out (fewer peers!) and the data you receive. Hence you have a greater chance of being late to see a transaction, if for whatever reason it did not reach the very few (one?) other node you connected to, or because few peers mean you are at an elevated risk of simultaneously lose connection to all of them, being cut off from the bitcoin network briefly.
Modify your client in a sensible way. Maybe you can live with relaying new transactions, but throttling bulk downloads of the entire blockchain? This could potentially have a huge impact on your outgoing (and total) bandwidth, whilst offering the potential for very sensible overall behavior. Consider that it could even make sense for the mainline bitcoind if alternative means of bulk download of the blockchain could be implemented---and as long as we find mirrors for them, this should be doable. In fact, by putting a "blockchain mirror" part of your site behind a free cloudflare account to serve static content at zero cost, you could do it!
May I suggest that option 3 could be the way to go? If the necessary modifications to bitcoind are a problem for you, I could help (or even do it all), although I am sorry to say I probably couldn't do it for free.