So for instance length 10 passwords each character from a list of 64 characters (the usual [a-zA-Z0-9] plus some special characters, minus confusable ones) is generated with 60 bits.

Increasing that to 12 characters gets to 72 bit, beyond that is hard to manage. Rainbow tables is about getting into an account from hashes, and doesn't typically actually resolve the actual password used, but something that instead hashes to the same thing. (In a rainbow attack you would hash H(X) then H(H(X)) then H(H(H(X))) etc, eventually for every hash you have something that hashes to that hash. Obviously this only works for small hash lengths and are what salts were designed to protect against.

But you're not hashing actual passwords, you're hashing the random results. When you're hashing passwords, those are dictionary attacks. If there's no salt or a weak (single-site-salt) salt then you can pre-hash a whole dictionary. Otherwise you have to hash a dictionary for each salt. But 60 random bits are unlikely to appear in any dictionary attack.

I'm not saying 60 bits of entropy in a password is enough to protect against a targeted attack, but it's enough to stop the password being found through a dictionary or cheap attack, which is all you can really protect for (you shouldn't re-use passwords anyway), the rest is up to the site operator to secure your password with hashing, at which point the salt has more entropy than your password anyway.

For a master password I'd obviously recommend going a lot stronger.

Ultimately, if a database has been completely owned, then you can't really protect against someone getting into that account, they could just do an "UPDATE users SET password=null" after all. So eliminate all password re-use, prevent your passwords being dictionary guessable, and secure your password list with a very strong master password.