Bruteforce hashes
You could bruteforce the hash that is stored in the database.
WordPress uses phpass for hashing. Per default, WordPress does not use blowfish or similar, but just md5 with an iteration count of 8192. If you just want to find really bad passwords, bruteforcing is certainly feasible.
But I would consider this a rather big violation of the trust that the users put in you, so I would not recommend this approach.
Analyze their passwords when logging in
You could add a script that intercepts all requests to WordPress login scripts, and log or analyze the passwords, as they are in plaintext at that point.
Of course, this only catches weak passwords once a user actually logs in. If they have abandoned their site or are rather inactive, it may take a while for you to discover that they use a weak password.
I would consider this an even bigger violation than bruteforcing the hashes, and it also carries some security concerns with it (if you store the passwords in plaintext, this would obviously be a concern, but even if not, you may accidentally store some information from the analysis which may help an attacker).
Implement a Password Policy (and force users to change their passwords)
You could implement a password policy. When a user submits a new password, you would check if it complies with your policy or not (ideally, this would happen server-side, not client-side via JavaScript).
Writing a good password policy is difficult, so take a look at existing policies to help you here.
Of course, old passwords are not affected by the policy, so you need to force users to change their old passwords to comply with the policy
Limit Damage
Enforcing strong passwords can certainly be a good idea, but ideally, a hacked WordPress instance shouldn't really affect you as the webmaster.
You should want to limit the damage once an attacker has gained access to a WordPress installation. Ideally, you would want that only that one instance is affected, not your whole server (so you may worry about an attacker putting indecent content on a website - just like a valid user might do - , but not about code execution, or other malicious activity).
This is a rather broad topic, but some points include: DISALLOW_FILE_EDIT
, limited the use of plugins (as they are far less securely coded than WordPress itself), disallow JavaScript (eg with multisites, only super-admins have the right to post JavaScript, not admins), etc.