If the wallet is unencrypted (which is the target demographic for wallet-stealing trojans), then a trojan or malicious java applet can simply open the file, locate the relevant segments of data (since the structure of the wallet will be public knowledge as Bitcoin is opensource) and only transmit those. The attacker can then construct a new, padded wallet file at his leisure using the stolen data and afterwards access the funds.
I was about to post this. Unless you change the way private keys are generated and work, which would 1) invalidate existing private keys, and 2) make brain wallets, online generators and paper wallet generators useless, there's not much one can do to increase the file size short of padding it which wouldn't really protect it from an attacker.
Nope, the "unencrypted default wallet" can be simply a wallet encrypted with the password "bitcoin".
I mean, the java applet cannot open and locate the relevant segments of data without decrypting.
So the Bitcoin-QT client by default encrypts wallet with "bitcoin" but to the user is unencrypted.
If you dont setup a password the wallet is still encrypted (by a know password "bitcoin") so the client dont prompt for a password.
1 day after such a change goes live, malware writers will have included a function to decrypt using the default password and then try to read it. If someone isn't encrypting his wallet today, he won't bother changing the default encryption password.
The only real way around this issue is to prompt users to provide an encryption password whenever Bitcoin-qt is launched with an unencrypted wallet.dat. Basically force users to use encryption. But if that's desirable is debatable.