SQL Server "Always Encrypted" does look like a very cool product but we do not have an exact feature to match it. Instead, we have multiple products or features that can help with this scenario that have been available as far back as Oracle 8i. As you've mentioned, there is TDE for tablespace or column encryption which transparently decrypts the data for the requesting SQL query. That solves the "side channel" attack and protects your data at rest, in RMAN backups, and in Data Pump Exports. The advantage of TDE is with tablespace encryption, so everything gets encrypted and you don't have to retrofit it, object-by-object, table-by-table, column-by-column, in the future. Again, it doesn't quite fit what you're looking for with "Always Encrypted" but let's keep going..
Another option that was mentioned was Oracle Database Vault (DV). We would recommend Database Vault to separate users who do not need to access sensitive data. This has the benefit of protecting privileges or roles, like preventing a user from using the CONNECT role to login from a non-approved host, IP address, or client program/module. Another advantage is being able to protect the application data from the application account - for example, developer's shouldn't login with the application credentials and if they do they won't be able to query the data. Again, with DV, you don't have to perform this type of protection on an object-by-object, table-by-table, or column-by-column basis. Database Vault is built-in to the kernel of the database so it travels with your database to other environments (containers, non-production, Data Guard standby DBs, etc.) and protects the data during an RMAN backup/restore operation. It doesn't do exactly what you're looking but I think it provides much more long-term, strategic, value than a column-level, client-side, encryption technique does.
We have other solutions that can 'mask' or 'redact' the column value itself, such as Data Redaction, Virtual Private Database (VPD), Label Security (OLS), and Real Application Security (RAS). With these you are in the driver's seat - you can keep them simple or make them as robust as you need. Do you want to make decisions to show the data based on LDAP groups or roles? You can do that too. Do you want to make decisions based on client program, client module, client IP, time of day, day of week, or just about anything else the database can learn about the client? You can do that too.
We believe that by keeping these security policies in the database we can centralize the controls and ensure that performance does not degrade due to large client-side encrypt and decrypt operations or the fact that the RDBMS optimizer doesn't know enough about the data to make parsing, pruning, compressing, or indexing decisions. Oracle's RDBMS kernel-based controls also have the advantage of not changing anything on the client or application levels, ensuring, no matter which application or client connects, they can all take advantage of the same security products. There are no certificates to deploy, manage or expire. There are no additional drivers to deploy.
If these controls aren't sufficient and you still need to do some level of Application encryption, there are third-party products which can offer something similar, for every major RDBMS, but please be careful about the application or client-side modifications required and the potential performance impact from the RDBMS not having any useful "insight" into the type of data, distribution of data, not being able to compress/deduplicate/index the data, etc.
If you'd like to discuss further, or learn more about Oracle's Database Security offerings, we have monthly "Office Hours" with Oracle Database Security Product Managers. They are held live on the second Thursday of the month and available as recordings in case you missed it or want to see previous events. You can sign up on AskTom's Office Hours section or by going to this URL: https://asktom.oracle.com/pls/apex/asktom.search?oh=3661