Summary. This is a clever idea that in principle might help improve security a little bit, but in practice probably doesn't help enough to be worthwhile. To really evaluate the idea, you have to measure quantitatively how much it helps, and when you do that, I think you find that the idea provides almost-negligible benefit. Nonetheless, it is a clever idea and one that in some sense "almost worked". I salute the author of this idea for thinking outside the box. Even though the idea turns out not to be useful, at least the author was trying something creative and innovative.
The purpose. Let's be clear on what the goals are for this scheme. It is not intended to be perfect: it not intended to make password-hashing impossible, merely to make it a little bit more expensive. So, to measure how much it helps, we need to measure exactly how much more expensive it makes password-cracking (see below). Also, this proposal is not intended a replacement for using a proper password hashing function (scrypt, bcrypt, or PBKDF2), but rather a supplement. It might add only a modest amount of additional security, but hey, I'd take anything I can get: if it significantly increases the cost to the attacker, at essentially no increase in cost to the good guys, that would be a great tradeoff.
Unfortunately, it turns out that things are not so rosy. The benefit is negligible.
Database size. Let me start off by refuting one argument that I totally don't buy at all. One person raised the suggestion that if you add enough bogus chaff to the list of password hashes, then the database will be too big for the attackers to steal. Baloney. I don't buy that argument at all. There are limits to how much chaff you can add, because you need to be able to store the database, back it up, etc. And given those limits, I don't believe the size will be a barrier to theft of the database. So let's just agree to take that argument off the table. Instead, I want to focus on the aspect of the proposal that I think does improve security.
Cost of password cracking. So how much does this proposal help? It forces an adversary who wants to crack your password to do many lookups into this table. That sounds like something that might make password-cracking expensive. But to see how much it helps, we need to measure precisely how much more expensive it makes password-cracking.
So, let's do a comparison between plain bcrypt (the current state-of-the-art), vs this proposal with bcrypt. Suppose the attacker has stolen a copy of the database. With plain bcrypt, if the attacker wants to try one billion guesses at my password, the attacker has to compute the bcrypt hash one billion times. We can make that go pretty slow, let's say 10 milliseconds per hash, so that might take about 100 million CPU-seconds, or about 4 CPU-months. So that's our baseline.
With this proposal, the attacker has to compute the bcrypt hash one billion times, and check each resulting password hash to see whether any of them appears in the database of password hashes. The latter sounds like it might be expensive: it could easily take 10 milliseconds to do a database lookup, so maybe we've introduced the cost from 10 milliseconds per guess to 20 milliseconds per guess? Sounding promising.
But wait, don't get too optimistic. The attacker can optimize the password-cracking attack if she uses just a little bit of ingenuity. Rather than checking each of the billion bcrypt-hashes, one by one, as they are generated, it is more efficient to batch them up and check them all at the end. The attacker could compute one billion bcrypt hashes, save all the results (all one billion of them), and then check whether there is any overlap between those billion bcrypt-hashes and the hashes in the database. The latter operation can be done quite efficiently; it is just a database join operation. For instance, you can concatenate the two lists, sort them, and look for duplicates (since you've sorted them, you know duplicates will be moved next to each other, so checking for duplicates becomes very easy). Such a merge-join operation can probably be done in minutes.
Let's tally up the total cost to the attacker if we are using this new proposal. The attacker spends about 4 CPU-months generating one billion bcrypt-hashes, then spends a few minutes doing the merge-join operation. The total time is 4 CPU-months plus a few CPU-minutes. Compare to if we use standard bcrypt hashing (without this proposal); there the attacker's cost would be 4 CPU-months. The difference is negligible.
Bottom line. In conclusion, if you take a careful look at the cost of password-cracking, you'll find that this proposal does not seem to increase the cost of password-cracking by a noticeable amount. Therefore, I do not believe this proposal is worth implementing: while it is a clever attempt, it doesn't really help in the end. That's a shame, but so it goes.