The UI will be simple. "Enter your password" "Enter your email address". The CPU demanding calculation is only done when you wish to create/re-create your wallet.
And I assume e-mail address is used as the salt? I would probably agree that would be joe-friendly and work as a salt.
The post I referenced originally mentioned 5 characters, which makes a rainbow attack trivial:
I am not sure he seriously intended to mean that people should choose 5 character passwords.
Creating a keypair is not computationally hard and can be implemented effectively and cheaply in hardware.
I'm not saying it's hard, I'm just saying it's very slow compared to (as an example) hashing. It won't stop the attack, but it will slow it enough to make a difference.
For long passwords the attack can be turned around by making a table of all addresses in use and continously guessing at passwords.
For appropriately long passwords, that attack is unlikely to yield any results within the span of the attacker's lifetime.
We want normal people to use Bitcoin. Asking the average Joe to memorize a complex 30 character password is error prone and will surely result in many lost wallets. The whole point of the salt and scrypt is that you can do with a shorter password that is easier to remember.
A 30 character password need not be complex to be secure. "Stinklers in the pie--with guymonds" would be just as memorable as "Fxh00w3e" without being short. I would think that a password like this should be written down and kept in a safe place where joe's next of kin will find it if necessary. Since it won't be used regularly, joe won't have the benefit of needing to recall it daily - which would help him remember it - like he would with other passwords.
I will definitely agree with you that the benefit of having a computationally expensive algorithm like scrypt is clearly beneficial, and that having the user provide his e-mail address (or any other non-secret datum he is unlikely to forget or confuse) as salt is an excellent user-friendly idea.