I don't think the account you log into the machine under for the installation of SQL Server has anything to do with the account that the service(s) run under afterwards. If you create domain accounts for the SQL Server services and specify those during installation, those are the accounts the services are configured to use, not the account you're logged in as. Also, when you specify those accounts, SQL Server sets up the minimum necessary permissions for the accounts so you don't need to go through the trouble of doing it manually. Also, if you change the service account later through Enterprise Manager, it sets up the appropriate permissions though it probably does not remove them from the other account.

Also, file-system encryption does put a hit on performance. Putting database files in an encrypted location is not recommended unless the sensitivity of the data warrants the performance hit and, even then, there are probably better options such as third-party solutions. Encrypting backups is not  bad idea but using file-level encryption is. NTFS encryption is too heavily dependant on the keys for the service accounts. If you want to encrypt your backups, go ahead and fork out some extra dough for LightSpeed for SQL Server (http://www.imceda.com) or something similar. It will perform better and has the added bonus of providing encryption and compression simulataneously which NTFS does not permit.