I see two qualities of a "rainbow table resistant hash"
- Pre-computation of hashes very expensive. The attacker cannot just hash every word in the dictionary, they have to hash every word in the dictionary with every possible salt. This grows exponentially with the size of the salt.
- You want to make it so that calculations attacking one user do not help you in attacking a another user. So if the attacker steals your hashes, if they break one user's password, that doesn't help them break anyone else's password.
Using HMAC with one global key gets you the first quality, but not the second. If they are able to break one user's password, they have (with high probability) also found your global key. Now breaking other users' passwords is much easier. In essence, what you are proposing is using (a global) pepper with no salt*.
So say you decide to add some salt into the mix and still want to use HMAC. I still wouldn't recommend that. HMAC is very easy to calculate and can scale well with powerful hardware. Instead, you want something that is slow on very powerful hardware. Something like PBKDF2 (which actually uses HMAC under the hood) or bcrypt. See here for more discussion on password hashing algorithms and how they compare.
* You could put it all on some grilled blowfish for a tasty treat, but that might be a question for another site.