We could add another layer that negotiates transactions before they happen, but as long as an address can be found, there is no possible way to prevent someone from sending to it.
Yes, this is what we're looking for - now, how to
prevent the local wallet from accepting the incoming TX, so it will remain unredeemed...
It wasn't a great example, but I wanted to suggest there might be any number of reasons a user would want his client to simply refuse to acknowledge certain transactions. I also wanted to avoid having the bigbadman come at all by not having his money. Maybe a better example would be a government sting operation?

Basically what you're asking is impossible. The only way to protect yourself from arbitrary government confiscation is either
A: Keep records and cough up like a good little peon if/when they come breaking down your door.
B: Keep your servers behind Tor and don't advertise any payment addresses publicly, nor make any public connection between you and your service.
C: Keep a blacklist of traceable money that came from an exchange so that you only accept pre-laundered money. Seems kind of stupid imo.
You could possibly use a reverse escrow, but you're still talking about single handedly policing the entire BTC economy for money that you will accept and money that you won't. The whole point of BTC is that your money is your personal responsibility, and if it's stolen, too bad. The correct solution economically is to maintain some form of insurance (like a bank does to cover defaults) and to minimize the side channels by which your accounts can be compromised.
If running a gambling operation happens to be illegal where you live, your local government may throw you in jail anyway whether or not you're declared guilty of laundering.
Personally I agree with Eto's solution, which was basically the inspiration for my idea (along with a suggestion by David Schwartz). My idea is basically to have a separate key type for encrypting messages, which can be sent as part of a tx. The message format would be standardized, with the only unencrypted parts being the first and last digits of the receipt address. To find out if a message is for you, you simply decrypt any messages with a first/last digit matching those you own and see if any of them come out with the correct formatting. Any return addresses or text replies are encrypted and only available to the recipient, whose own address is only slightly revealed.
That way all funding details can be worked out privately
before an account is funded without exposing you to side channels where your information could be stolen or used for illicit purposes without your prior consent. Since they can provide you with a signature pubkey for withdrawing funds, it doesn't matter whether they provide the return account immediately or later or if they change it since you can verify that it's the same person who opened the account.
That way, if you're paranoid, you don't have to publish a public funding address anywhere, even for donations. You can require people to pm you to get an address to donate to first, and/or keep a separate address for accepting anonymous donations (which would also be possible with my system). I've never heard of a BTC police sting occurring (yet), but it's not impossible. It's possible to minimize your risk of that happening to you, but that's really not a subject that belongs in the development forum IMO.