I am not sure this applies in this case. Rainbow attacks help attackers take a large number of hashes and try to recover plaintext from as many as possible with the same effort. In wallet generation, the hashes are used as private keys which the attacker has no access to (or else if he gets the private keys, his attack has already succeeded, there's no value in recovering the plaintext itself). This advice is useful for someone operating a website and storing hashed passwords in a database, but I believe it has no application for wallet generation.
The attacker would not search for the private keys alone, he would calculate the private/public key and their corresponding address for all passwords up to a certain length (depending on his capacity), and store them in a table. Then he would scan incoming blocks for transactions that send coins to addresses that match his table. This allows him to harvest transaction outputs sending coins to addresses based on private keys that are generated on weak passwords. With one such table he can attack everyone using this scheme in parallel.
If the key generation is based on both a password and something that is globally unique (such as an email address) the attacker will have to either calculate really really big tables (unfeasible) or make a targeted attack against a single user (provided that he knows his email address), yielding much less profit.
Although I agree that the linked wiki article discusses it and recommends the user enter a "salt"... what practical difference would there be between the user entering a "salt" into a separate field, versus simply appending some extra characters to their passphrase? They will be concatenated anyway, so none from what I can tell. Salt in most other contexts is not something chosen by a user, rather it is something added by an application outside the user's control.
They aren't really concatenated, but seperate inputs to scrypt, which generates the seed used for deriving keys. The idea with the salt is that it is easy to remember, unique, and not a secret. In practical terms it allows for stronger security without having the user remember/keep-secret a longer password. In a UI I would always keep this as two seperate fields, as this makes it easier for the user to understand that there is a secret component and a unique component of his wallet.
With deterministic wallets we cannot rely on a central component generating the salt. We need the salt to be the same whenever we wish to recreate the wallet.