I think that's not true - you'd have to generate new rainbow tables for each user for gawker. So this method would indeed make rainbow tables impractical.
edit: but I think the rest of what you said is fine.
In addition to tptacek's comment off yours, rainbow tables aren't remotely necessary to check the most common passwords, gaining thousands of them in seconds. The salt's there. Just hash "password1" against all the salts in the database - you're nigh-guaranteed to get a bunch, associated with their username. Viola, you've likely got their email account.
Similarly, any sufficiently-complex-and-long (at best: random) password in those hashes is effectively secure. Rainbow tables typically only handle up to a dozen-ish characters long, and specific common passwords, frequently only alphanumeric values to limit the problem space. You're stuck brute-forcing each one effectively separately because you don't have enough storage on the planet to rainbow-table my 30-character random-ascii password. For instance, freerainbowtables.com recently cracked "racsivrv" and their table is 232GB. [1]
And even if you do find a match, it's simply a hash-collision. There are an infinite number of those. You might have my password, you might just have a random string that behaves like it with that salt. If it's random, you can't tell until you try it on other sites that I use the same password on. If it's a word, there's probably just the one (of reasonable length).
Rough sizes and overall idea (though I don't tend to link to codinghorror for accurate details, it's a pretty readable overview): http://www.codinghorror.com/blog/2007/09/rainbow-hash-cracki... Very specifically from that link, "You'll also note that that passphrases, which I am a big fan of, are immune to this technique due to their length."
I think that's not true - you'd have to generate new rainbow tables for each user for gawker. So this method would indeed make rainbow tables impractical.
edit: but I think the rest of what you said is fine.