What you are trying to do won't work because
decrypt function is not going to receive the KMS key you encrypted the data with.
Essentially, when you set up KMS it generates a key pair consisting of a public key and a private key. These are generated on a Hardware Security Module (HSM) and the public key is something you can query the KMS api for. The private key remains on the HSM and never leaves it. You can hand data to it for decryption using the api, but you cannot receive the key; the whole point of using KMS is that the private key remains secret, even from you.
What setting up KMS on RDS postgres does get you is that your tablespace and your backups are encrypted. If you also want to do row level encryption over and above the data at rest protections that are provided when you create your database with the
--storage-encrypted True flag set; you will need to manage another set of keys for that.
The right way to do that is to generate symmetric encryption keys that are then encrypted with a KMS master key. Your application would use the API to decrypt those keys on start and would retain them in memory, passing them to the database with every query that needed decrypt operations.
Indexing an encrypted column is impossible by definition since the cryptext should appear random to anyone who does not have the key. The query you posted above would be slow even if you had the key to look at the column since it would have to perform the decryption operation for every row. Generally speaking if you are using row level encryption you want to be encrypting dependent attributes not key attributes; since selection, sorting and searching all require access to the plaintext of the values.