Since AES_ENCRYPT/DECRYPT are just functions that you can apply to your data as part of the query, I don't see how that would cause lock in. If you write your code to use it, then change your mind and decide its better to have it handled by your front-end, you'll just have to:
- Change your queries/view so they don't use those functions anymore;
- Change the code calling those queries and have them encrypt/decrypt the data using the same algorithm.
(Those two changes must come into effect simultaneously, of course; the converse operation is also possible)
The main advantage I see in doing it in the front end is that you can choose other values for the key size and padding (MySQL uses 128bits and 16 respectively), if needed. You can also change the algorithm more easily, if eventually you decide AES is not the best choice.
I left aside security implications of your setup, since it's hard to tell from which kinds of risks you're trying to protect your data. However, I agree with @Kevin that you get a little more security (by obscurity) if you don't explicitly show the algorithm in the database, assuming your code is kept secret.
Edit: seems I misunderstood Kevin's argument; while I agree that hiding the algorithm is mostly pointless, hacking your server is not the only way for an attacker to access your database - the processes you use to make regular backups of it, including offline ones, creates more opportunities for data leaks that does not necessarily applies to the code (which might have its own process vulnerabilities as well). But in the end what matters most is how strong and well-protected are your encryption key(s).