The suggestion by pc is a great idea!
I would definitely pick 0.01 BTC coins for this purpose, as it is always a good idea to stay above the "dust spam" limit.
// To limit dust spam, require MIN_TX_FEE/MIN_RELAY_TX_FEE if any output is less than 0.01
if (nMinFee < nBaseFee)
BOOST_FOREACH(const CTxOut& txout, vout)
if (txout.nValue < CENT)
nMinFee = nBaseFee;
Where CENT is defined to be 1000000 (which is 0.01 BTC).
As others have pointed out, it's probably not such a good idea though, to reuse the same 0.01 BTC frequently. This would create transactions that depend on unconfirmed 0.01 BTC coins, which looks pretty spammy. But it's easy to work around: I would just put, let's say, 10 BTC worth of 0.01 BTC coins at the green address, to always have some available, which have a number of confirmations under their belt. And if you run out of confirmed 0.01 BTC coins, then that's a signal that you have too many unconfirmed transactions pending and should be slowing down in creating them anyway.
This sounds like a great implementation strategy to me. "Greenifying" a transaction is then basically just a post-processing step, which adds one of the available 0.01 BTC coins as an input and an extra output to send it back to the green address. This sounds modular enough, that a clean patch for this should be possible. I will probably switch Instawallet over to this mechanism at some point.