Apply Group Policy depending on group membership?

I'm confused by the title of the question - the solution given by oBdA will certainly work but quite what your question has to do with the title has me perplexed
>> Apply Group Policy depending on group membership << 

This is possible with security filtering http://technet2.microsoft.com/windowsserver/en/library/65424a58-aff3-4e1e-a3a1-59878cbcf0051033.mspx

I had initially thought I would try to apply a group policy based on a combination of the OU of user and if they were a member of a particular AD security group or not.  As I wrote the question, I thought I might be attempting to do something that was either impossible, or could be solved more easily through a method toher than the one I was proposing.  So, I decided to make my goal more generic and see what was suggested.  I neglected to change my title....

... It happens :-)

If I enable loopback processing, is it possible to not apply a user based policy for administrators?  Since I am locking down the desktop, I would like to have the workstation be open if an administrator logs on to it.  I suppose I could move the workstation to an OU that didn't have loopback processing enabled if I needed to, but it would be nice to not need to.

You can use security group filtering for this: create a group "GPO-RestrictedUsers" or whatever, add the users that should be restricted, and replace the default "Authenticated Users" in the permissions for the GPO with this group. That way, only members of this group will be restricted.
Another possibility would be to open the Advanced permissions in the Delegation tab of the GPMC, and Deny the "Apply" permission to the Administrators group.

Is it possible to enable loopback processing, and implement security filtering on the user policy that is being applied through the loopback processing?

Yes, that's why I suggested it.
For your own convenience, do as I (well, after a fashion) suggested in my first post: create a policy *only* for loopback (and other *computer* configuration settings), add/link *new* GPOs for *user* configuration policies (and configure permissions on these user GPOs).
The loopback policy does *NOT* have to be in the same GPO as the user policies you want to implement!

I hate to ask, but in your first post, you say to create an OU for the machines in question, and enable the loopback processing option for the OU.  Is this done by enabling the loopback processing option in a policy linked to that OU?  And in your last post you mention that the loopback policy does not have to be in the same GPO as the user policies I wish to implement, are you saying that any user GPOs that are linked to an OU, that has a policy linked to it that has loopback processing enabled, will apply all the user settings contained within those linked policy objects?

I guess I am confused about how I am to enable loopback processing on an OU...

Yes, the loopback policy is a computer policy and will be applied to all computer objects in or under the OU to which it is linked (unless you combine it with a security filtering group, which will work for computer accounts as well - note that if you add a computer account to a group, the machine needs to be restarted for the group membership change to be applied!).
And yes, as I said, once a Loopback is applied to a machine, all user configuration policies applied to this machine will be applied to all users logging on to this machine, regardless of where the user account resides in AD (again, unless the GPO is combined with a security filtering group).
Yes, loopback processing can be somewhat confusing until you get the hang of it.

Thank you for your patience and thoroughness.