I think what you are referring to is cell-level encryption, but using this feature requires changing the application. TDE (transparent database encryption) is another option, this encrypts the files on the disk, but they are decrypted in-memory, so anyone with direct access to the machine and sufficient privileges to look into the block buffer cache directly could access the data.
An alternative approach is to simply use the db_backupoperator role so the account the DBA uses can backup the database, but has no rights to look at the data. In this scenario, you would want to have the sa password written down and locked in a safe in case you ever do really need it.
Tho', as an aside, if you are worried about your DBA stealing your data, your problems are organizational, not technical. I work in a regulated industry myself and DBAs and SAs are carefully vetted (e.g. annual background checks) and we store data in the DB in BLOBs encrypted to which the application has the keys (and no-one has logins on both the machine with the data and the machine with the keys). However, it is possible to take this strategy too far. On one of my current projects, I need to use LDAP for authentication. There is some problem, but there is no-one who is allowed to log into both the DB box and the LDAP box, so diagnosing the issue is very difficult - which for the business means, expensive.