You cannot realistically check the strength of any password that has already been hashed when sent to you. Hash functions are One Way Functions by design, meaning that you are not supposed to be able to reverse the hash and get any meaningful information about the input.
However, you could fairly easily verify that the password does not belong to a short list of common, weak passwords, such as the empty string "", "abc", "123", "password", etc. You do that simply by repeating the client side hashing procedure with these inputs server side, and check for equality. The length of the list of such weak password will be limited by performance constraints. Since the hash submitted by the client is salted, the server will have to build this list anew for each registration and password change.
Consequently, the bulk of the password sanity checks will have to be performed client side, provided that the password is only sent as a hash value.
Your idea about a hybrid registration scheme, where the password is sent as plain text to the server just for a quick checkup, is not ideal, as you already mentioned. To begin with, you do not gain much by having the client send a plain-text password, instead of a plain hash of the same password. Most of the sanity checks that benefit from having a plain text password, could easily be performed client side. The bulk of the server side testing should probably best be performed as a search in a database of hashes of common weak passwords (a Rainbow Table).
That said, not finding the hash in such a database table, is no guarantee that the password is strong enough. A long password that is the concatenation of three or four random words from a dictionary, might be easily spotted if you have access to the plain text password, but would probably not be an entry even in a reasonably large rainbow table.