Forgive me if this has already been covered, but I think the idea of preventing people from signing up with popular passwords is at least a bit more problematic than it is helpful.
Initially I was going to complain that a mere 10,000 wasted attempts per hash wasn't that much, but it turns out that even in 2015 bcrypt, and especially scrypt, hold up incredibly well even with GPU hashing.
That said, I think what you're looking at is adding at most 20 minutes per hash (assuming they have to use CPUs) onto the cracking time if you're using a bcrypt factor of 10 or scrypt factor of 13. Check out this video for some interesting stats on that http://video.adm.ntnu.no/pres/5499318fcce2c.
And what do you trade for that? A large majority of your users, for most sites, are then forced to use a password that they don't normally use. A password they're likely to forget. If they even bother continuing to sign up after some stupid website told them their password was dumb. And it's not like the acceptable password they choose is going to be massively better, it'll probably still be in the top 100,000 or million passwords guessed by a competent cracking program.
Philosophically, I think it's my responsibility to assume that every single one of my users is so unconcerned about security that they really will make their password 'password' (or whatever minimum additions to that are required to fit my stated requirements). The best I can do is pick password-related technologies and designs that protect them as much as possible in the event of a breach.
The user's responsibility, OTOH, is to assume that I'm so unconcerned with their security that I'll store their passwords in plaintext. In that case they'd use a password manager, or insist upon a stronger technology like PAKE and/or two-factor auth. Sadly not enough users assume this, but we also can't make them.