S/MIME lets users encrypt outgoing messages and attachments so that only intended recipients who have a digital identification (ID), also known as a certificate, can read them. With S/MIME, users can digitally sign a message, which provides the recipients with a way to verify the identity of the sender and that the message hasn’t been tampered with.

http://msdn.microsoft.com/en-us/library/dn643699.aspx

The User certificate template is definitely not the best  choice for email encryption and signing. First of all, I recommend using separate email and signing certificates. If you combine them (and archive the encryption certificate), then it is possible to recover a signing certificate (allowing impersonation).

I would recommend duplicating the following certificate templates:

Signing = Exchange Signature Only

Encryption = Exchange User

For each, enable autoenrollment for your target global or universal group. Ensure that you only have enabled E-mail name as a SAN.

2) The user will have to go into trust center once and once only. Outlook will automatically choose the correct certificates fro signing and encryption (as long as you use my recommendations above and only issue one certificate of each type to each user. Also ensure that no other certificates, like User or a copy of user, are deployed. Otherwise, they need to carefully choose the correct certificates.

3) There is no need to publish to gal as long as you enabled the Publish certificate in Active Directory option in the encryption certificate. Investigate the user’s userCertificate attribute. This is the attribute that contains the user’s certificate. The Publish To Gal button is a throwback to Exchange 5.x when user smime certificates (if X.509v3) were signed in a PKCS#7 envelope and published to the UserSMIMEcertificate attribute (to prove that they had an X.509v3 not an X.509 v1 certificate issued by KMS).