I've only created one database with column-level encryption for a live database so far, but I have done it by putting all code to decrypt and encrypt in stored procedures. This allows you to put any passphrases, etc. in the stored proc, which is then encrypted with the WITH ENCRYPTION clause. Then, in the SPROC, you can log anyone that uses the SPROC, by saving to a audit table who ran it with what parameters (record id values, dates, etc.). Just give the permissions to run the SPROC to the ones that should be running it.
This keeps you from moving any keys across the network, and you can make it to where the SPROC never gives ALL records of a table. That will keep anyone from being able to dump all the data.
If using column-level encryption, safeguard the backups. Anybody can get the backup and restore it to their own SQL Server system and run the SPROCs to get the information, since they would be an SA for their system. I know it is depricated, but you can use the backup with password option, so that nobody can restore the .bak without the password, and the column-level encryption will encrypt those columns of sensitive information so the .bak can't be read with a text editor.
Of course TDE would do the part that encrypts the data at rest (the backup) much better, because it encrypts the live data, the backups, and the log file backups. However, it is different in the sense that once you have gained access to the table info, you can see all the data, since it acts like a normal database as seen from the user standpoint. Column-level encryption adds the additional barrier in that the user has to also have access to the keys to decrypt the data, in addition to access to the table.
Hope this helps.