Based on my understanding of the way wallet.dat works, this might work awhile theoretically, but complications would sooner or later cause trouble, and I'd say it wouldn't be recommended.
Let's try this:
At time zero, you duplicate your wallet.dat and run two independent clients, A and B.
If you receive anything to addresses already given out before time zero, obviously both clients will see the income, assuming you don't do any spends.
For awhile, depending on the state of the wallet.dat's keypool at the instant it was forked, If you do a spend on client A, and ensure the client B has caught up with the blockchain before doing anything with it, you'll see the spend you made with client A and your balances on both A and B will remain consistent.
Eventually, your keypool will be exhausted and the client will replenish it with fresh keys. These keys will differ between the two clients. I think then, at this point, a spend on client A will show up in client B in an interesting way. It may show up as two spends, one matching the transaction you remembered making on client A, and the other as some other amount to an address you don't recognize. And, the balances between the two will become inconsistent.
What's happened there was that client A gathered up sufficient bitcoin from unredeemed inputs to make the indicated spend, and spent out the remainder to the next "hidden" address in client A's wallet.dat. But over on client B, it's wallet.dat doesn't contain this key. So it lends the appearance that "someone" reached inside and stole some bitcoin.
Worse, I think, is that if the two clients are not kept rigidly in-sync with the blockchain before new transactions are attempted, you might inadvertently double-spend some bitcoin from one of the clients. And I think this might be possible even if the balance figure seemed to show you had plenty to spend. So you'd get some transactions that would stick in the blockchain unconfirmed, as the chain adopts one or the other of the spends.
This stuff would either start to wreak general havoc, depending on how much transacting you do with your clients. It might be difficult to get the balances back into agreement, as some bitcoin would be held under keys only on client A, some under keys only on client B, and some under keys in common to the wallet.dat's of both A and B. A fine mess!
A better solution is to maintain independent wallet.dats, and spend a necessary balance between them as required. Leaving a home client for a mobile client? E-mail yourself a receive address from the mobile client, and spend a desired balance onto it from the home client. Then travel on.
Or, you could use an intermediary like a Mt. Gox account you own (assuming you trust them). From the home client, spend all or a desired amount into your Gox account. Then, from the road, withdraw the BTC from the Mt. Gox account to your mobile client. Do the reverse when you're back home and ready to use the home client again.
Be sure to have a backup strategy for the wallet.dats of each client!
As I finish writing this, MoonShadow makes a very excellent point about the theft potential for the mobile client. It's a similar risk as having you physical wallet stolen while out on the town. And, perhaps still more reason to start considering my not-yet-fully-formed-but-important notions I make in the rant below, and have elsewhere on this forum a number of times already.
<potentially misguided evangelistic rant>
To me, this exposes yet another way the architecture of wallet.dat and its notions of keys and keypools can get users innocently into serious trouble. You never know precisely what's going on under the hood of your wallet.dat. To me, it would be better if there was an option to make this internal system of keys which testify to the network about your ownership of bitcoin values, more like the way standard public-key crypto works in systems a-la OpenPGP. The client could have switches to allow users to choose the behavior they wished to use.
If wallet.dat were instead replaced with something a bit more like OpenPGP-style keyrings, you could choose to create a single static key for yourself. Your balance would accrue to this single key, and be spent away from this single key. You could copy this key from client to client and have access to the same balance (assuming the blockchain is up-to-date on the client). You could vault-away this key upon creation and not have to worry about making periodic backups of wallet.dat. You lose anonymity. Your transactions become more easily traced back to you, because "you" always show up under the same key in the blockchain. It's a tradeoff I think a lot of folks might be happy to make. This is an issue with the current official client. If the official developers have no interest, it certainly wouldn't preclude some other motivated devs to create a compatible client which introduces this operational difference.
</rant>
