Unfortunately as etotheipi points out, there is currently no functionality that allows successive pending withdrawals to replace each other in the blockchain. I'm sure that other major changes would need to take place.
Just an interesting idea, I'm wondering if anyone else has comment on it.
I like your usecase, I agree it has the potential to stop a lot of hacking attempts, though it somewhat goes against the idea that once bitcoins are sent they are gone.
Would they have to go in the block chain? If the pending transaction was somehow prevented from being confirmed for say 24 hours or so, the owner would still see there is a pending transaction and could send a new version of a transaction to change the destination (it would have to be in the memory pool for that length of time). Though like you point out, only if there is a way to always force transactions from not entering the block chain for a set period of time, and if there is always a way to +1 the version number, otherwise an attacker would just use the highest version.
It might be cool to allow users to set that the bulk of their coins can not be spent without X days of wait time. And maybe another percent of their coins couldn't be confirmed without Y hours of wait time (all determined by the owner). Then if the user wanted to make a large purchase they would just choose to not renew their X days of wait time (or shorten it) on the bulk of their coins.
This would also prevent the transaction from sitting in the memory pool for a length of time. Say a user locks some amount of their coins for 4 days, they could renew this 4 day lock every 24 hours. So if an attacker knew the private keys they would constantly be unable to post a transaction until they prevented the user from locking their coins. However this could obviously go the other way, an attacker could constantly lock your coins from your own use, basically destroying those coins.
I'm not sure how you might achieve this within today's constraints but it is interesting.