You would essentially me using encryption as a "pepper". I.e. a salt that is shared among all the database entries and is not stored with the database. Normally this is just another random value that is added to the password hash but as far as I can tell with a few minutes reflection, encrypting the password instead before hashing should accomplish the same thing.
Here's the thing with peppers: they don't increase the brute force complexity at all. What they do accomplish is to make it impossible to brute force at all from only a dump of the password hashes. Directly attacking a password hash without knowing the pepper becomes roughly equivalent to brute-forcing the random value used as an encryption key/pepper value, which is not possible at all with a sufficiently large key/pepper value. This can add security through defense in depth because the attacker must compromise your system more fully or compromise multiple systems in order to find the pepper before attacking you. For example, your password database would no longer be at risk from a simple SQL injection because the attacker would not obtain your pepper. But, depending on how the key is stored, obtaining read access to all files on your web server could, could yield both the password database and the pepper. If this happens, the password is only protected by a single round of your hash. Using a nonstandard pepper method, in your case using encryption, does not help in this scenario. Symmetric encryption is too fast to make a difference, and while asymmetric encryption takes longer, it is not clearly better than just using a larger number of iterations on a standard password hash. Even if you use a miniscule iteration count in order to compare it to a round of asymmetric encryption, your method is almost certainly less secure than a purpose-built hash like Argon2, which spent 2 years in development and testing by expert cryptographers before winning the Password Hashing Competition and has received fixes and improvements since in order to combat weaknesses specific to the task of hashing passwords. Using a normal number of iterations, to bring the hashing time up to tenths of a second or more per password, but with a standard pepper, would greatly surpass the security of your algorithm even with a weaker hash like bcrypt or PBKDF-2.
In short: just use a standard password hash with a high number of iterations and solve the DOS problem in a different way. Add a pepper if you want more defense-in-depth and to prevent compromise by some common attacks but don't fully rely on it for your security.