When a Windows Service is started by the Service Control Manager, the process executes as a particular user just as with any other process running on the OS.
There are a number of "built-in" user accounts that are used for running Windows Services. You can see the complete set of Windows Services and the account they run as (called "Log On As" in Windows 7) if you look at the "Services" node within Computer Management".
From my experience, when we want a Windows Service to talk to the DB using integrated security we take the second approach below:
1) Assign one of the built-in accounts as the "Log On As" account and add this account as a login on the SQL Server instance with the appropriate DB permissions
2) Use/create a local or domain account for the Windows Service to use and then add this account as a login with the appropriate DB permissions. It is possible thru the installer to prompt for the user account credentials during the installation of the service.
I can't claim to be expert enough to point out all pros and cons of each approach, however it's worth considering the following:
with approach 1 all services and processes that run as the selected built-in account will have permission to access you database. This is not the case with approach 2.
with approach 1 the password configuration is managed by the machine itself but with approach 2 the password can be managed by the administrators and also conform to any required security policies in place.
I hope this helps