As @aviv pointed out, revealing to a user that some other user also has the same password is a problem.
If you really intend to maintain such statistics, then you have another inherent problem: the "statistics engine" can only help any attacker, since it outputs a list of passwords that are in use. Even a reduced form which merely says "this password is already used by somebody else" allows the attacker to break passwords much faster, for the following reason. Good password hashing uses salts so that attackers cannot try to break 10 millions of passwords in parallel. If hashing is unsalted, then the attacker can hash a potential password once, and compare the resulting hash value against all 10 millions hashes; in that way, the attacker breaks 10 millions of passwords for the cost of breaking one. Salts prevent that. Salts are good.
Now suppose that you have a statistics engine which can tell you, when a user enters his new password, whether that password is already used by somebody else or not (even without telling how many users have chosen it). Then an attacker, who could get a copy of your database (you hash passwords precisely because you fear that scenario), can run the same "engine" on his own computers. Thus, he can "submit" a potential password to the engine, and learn whether it is used by one of the 10 millions of users or not. This allows him to prune his huge list of potential passwords down to the ones that are really worth the effort: instead of trying one billion passwords on each hashed value, he will try only the 1000 or so passwords for which he got hits from the statistics engine. You've just made the attacker's task one million times easier.
The only way out of this problem is to make sure that the attacker will never be able to access the statistics (which, in turns, implies that they won't be shown to the users themselves). This suggests the following:
When a user chooses his password, the password is hashed as usual (with bcrypt or anything similar).
The password is also asymmetrically encrypted with a given RSA public key. Asymmetric encryption is randomized, so the encrypted results don't allow for dictionary attacks. A 2048-bit RSA key is enough to encrypt data elements up to 245 bytes, which ought to be enough for passwords.
The corresponding private key is kept on an offline machine (thus presumably immune to remote attacks). At regular intervals, the "statistics officer" gather the encrypted passwords from the server, transfers them to the offline machine (with a USB drive or something similar), decrypts them, and runs statistics.