Not to mention people will feel more secure
Yeah, a false
sense of security. As xeroc mentioned, once your machine is compromised, you cannot rely on any of these tricks.
The real solution as usual is: multisig.
The light wallet server can serve double duty as the second signer in a 2-of-3 scheme.
The light wallet server has a public key L and corresponding private key l. Save L to a flash drive that also contains special trusted BitShares tools.
You use an offline trusted computer running a live Linux CD and the BitShares tools on the flash drive to generate a random private key pm (corresponding public key is Pm). Deterministically derive private key pw (corresponding public key is Pw) as hardened child key of pm with index 1 and private key ps as a hardened child key of pm with index 2. Deterministically derive private key ps1 (corresponding public key is Ps1) as hardened child key of ps with index 1. EC multiplication of ps1 and L gives S1. Use your own strong master passphrase m to encrypt pm and represent the encrypted key in brain-key form (passphrase consisting of a sequence of dictionary words) as b. Use your wallet passphrase w to encrypt pw as p. Save b, p, Pm, and Ps1 to a flash drive (also you can write down b on a paper backup). Plug in a security token to the machine and use the software tools to write S1 into its secure firmware (overwriting any previous secret stored in that location) and also adjust its clock if necessary. Then shut down the offline computer.
Take the flash drive to an online computer with the light wallet (or alternatively to a computer that will let you communicate p, Pm, and Ps1 to your smartphone/tablet via email / cloud / QR code). Let it import p, Pm, and Ps1 from the flash drive (or alternative source) and store it in its local storage. Then it should prompt you for your wallet passphrase w, decrypt p using the w into pw in memory, and then go through the process of letting you register a new account if public key Pw isn't already registered on the blockchain.
You type in the account name you want to use and it tells the light wallet server to generate a new transaction to register that account name to public key Pw on the blockchain, and as a part of its public account record it is specified that it is a public_account, it stores Ps1 as an additional key in the record called the "one-time security public key", and it also specified it wants to receive funds using a 2-of-3 multisig where the three addresses are the ones corresponding to the public keys Pw, Pm, and L. It receives this transaction, signs it using pw, and sends it back to the light wallet server so that the server can also sign it (to pay for its registration fees) and broadcast the transaction.
All funds sent to that account will automatically use that 2-of-3 multisig condition for withdrawal. Those funds could always be spent by the user alone (even if the light wallet server disappears) as long as the user can get access to the encrypted brain-key b (which should be backed up in multiple places including the flash drive, paper backup, and perhaps a cloud service) and knows the master passphrase m. But the usual way those funds will be spent is by signing the transaction with the private key pw that is decrypted in the memory of the light wallet (assuming the wallet passphrase is provided) and by the light wallet server using private key l. For the light wallet server to sign any transaction already signed by pw, it also needs the light wallet to provide a one-time password over their secure connection. This one-time password is deterministically generated from the current time and the shared secret S1 (which the light wallet server can generate using EC multiplication of the known public key Ps1 associated to the account on the blockchain and the server's private key l).
The shared secret S1 is not known to the computer running the light wallet (which is what provides multi-factor security). Instead it should be securely stored inside of the security token. Ideally, the hardware device is designed so that it is difficult to get the secret out of it, but it is theoretically possible to do so if the adversary has physical access to the token. Also, keep in mind that anyone could easily erase the secret if they could get physical access to it even for a short period of time (plus you could lose the device anyway and need to replace it). Whether the secret was erased or you purchased a new security token, you can always recover S1 by following the same procedure with the offline computer I described above (it is best if you first get Ps1 from the blockchain and provide that to the tool so that it is sure it is using the correct index to generate ps1 and thus S1), assuming you have the encrypted brain-key b and know the master passphrase m.
Also, if you lose the security token, it is probably best practice to replace the secret with a new one (even though it is unlikely for the adversary to be able to obtain it from the device). Or if the light wallet server is compromised (private key l is compromised), S1 is no longer safe to reuse. In either case, it must be possible to update the shared secret that the security token and light wallet server both use. You can get Ps1 from the blockchain (the one you are trying to replace) and take it to the offline computer. The software can then iterate through the indices it uses to generate hardened child keys from ps until it gets ps1 (corresponding to public key Ps1) and then go one index more and generate ps2 and its corresponding public key Ps2. From there is does EC multiplication of ps2 and L to generate S2, which it then stores on the hardware token. Also, the tools on the offline computer would construct a transaction (the flash drive would have to include some information stored by the light wallet that specified a balance controlled by the 2-of-3 multisig from which to pay the fee) to update the account record so that the "one-time security public key" is set to Ps2, and then it would sign that transaction with pm and pw and save it to the flash drive. The light wallet could then take that signed transaction and send it to the server to broadcast so that the blockchain is updated and the server knows to use the new S2 shared secret to generate one-time passwords.
So the end result of all of this is that you have your light wallet (mobile or desktop app) which stores some important information locally that is encrypted on disk by your wallet passphrase and can be recovered (the importants keys, not the transaction history) using the master key (pm). The master key can be recovered using the encrypted brain-key and the master passphrase. To actually use the light wallet to spend funds, the light wallet server would require you to enter a one-time code that is displayed (and frequently updating) on a separate small hardware device (the security token). Even if the computer storing the light wallet software is compromised, the attacker cannot just steal all of your funds if they do not possess your security token. However, if the light wallet is compromised, then the next time you go to make a transaction that requires the one-time code, the attacker can get the light wallet server to sign a transaction that steals your funds even though from your perspective the transaction was benign. For this reason, the light wallet server will impose spending rate limits. If you will be transferring funds to other accounts/addresses and including this transfer the accumulated value of funds transferred within a moving time window is over some threshold (which the light wallet server could provide ways for you to securely adjust), then the light wallet will refuse to sign your transaction and perhaps allow you to use other methods to authorize the transaction. For example, if you subscribed to a premium light wallet service that required a monthly fee (rather than just a small transaction fee per transaction), it could allow you to authorize a transaction that went over the spending rate limits if they could confirm your intent over a one-on-one phone call.