Banning specific passwords?

The theory is that you would like to run the same tools as the attacker. The attacker will run a list of "probable passwords" based on what he knows or guesses of the psychology of the users. John the Ripper is a well-known password cracking software which includes lots of "usual passwords" and rules commonly employed by users to derive witty passwords.

Your advantage is that the server code has access to the password itself when the user registered. Contrary to the attacker who must run each guess through a potentially expensive hashing process (and it can be heavy if you crank the bcrypt iteration count to its full power), your code can work on the actual stuff and do some optimizations such as, as you suggest, normalization to lowercase.

However I think this is not a very good idea on a general basis. The attacker is not restricted to openly available software; he can adjust his list of potential passwords to the actual target (e.g. using more derivations around the names of the children of the specific user whose password is under the fire of the attacker). Even keeping up with the list of "common weak passwords" is likely to be a tiresome process. Moreover, the user himself will enter the game: since password restrictions are felt as an irksome hindrance by users, they will use all their creativity to find even wittier password generation rules which evade your tests.

Enforcing complex password exclusion rules on the server is somehow fighting the attacker on his battleground, and will bring the user to the feast; the user may unfortunately (and unintentionally) help the attacker.

Therefore, I would recommend against such rules. What you need is the collaboration of the user, and you will have it by being transparent about the rules you employ; the user must be able to find a password which "passes your test" without entering a trial-and-error process. Nothing is more annoying than choosing ten successive passwords until one is finally accepted by a rigid server. You do not want to annoy the user, because an annoyed user will help attackers (he will not think about it like this, but that's the net effect). Explicit rules ("at least 8 characters, at least 1 digit") are much better for pedagogy.

And, of course, nothing beats proper education and training of users about the dangers of non-random passwords.

Sounds good in addition to other sane practices (e.g., bcrypt).

I'd use as large of a password blacklist as possible. If your password is in a disclosed list of 100000 passwords (or only different from a password in that list by one or two characters), its a bad password and GPUs can likely defeat it. Its also possible that someone is reusing that password. The only good reason to relax this criterion is if you don't want to frustrate your users who may turn to a competitor that allows weak passwords. (Also to state the obvious, don't use passwords from your own systems to build up this blacklisted password list--that's storing the password in plaintext an big no no.)

Additionally, you may want to create a password suggester feature that always generates a password that passes your criteria and have this pop up whenever a password fails. (Though still require the user to type it twice.)

I'd also make sure that your scheme doesn't inadvertently prevent strong passphrases. E.g., fork scorn loss cope endow yin is a great randomly created diceware passphrase and shouldn't be forbidden if one of the common blacklisted passwords reduced down to fork (and fork is contained within your passphrase).