Let us know how you go! As I mentioned above, the join domain portion should be essentially the same, so you may face a similar issue... but keen to hear if/when you resolve it.

Good news about the join!

Do you have a reference for IMU being deprecated on 2012R2? Will likely change approach for some sites.

Questions:
1.This can be achieved with the override_homedir option in sssd.conf. This takes several variables to construct the home directory. This essentially instructs sssd to intercept the homedir value it's getting from the directory and overwrite it (or in your case, provide one when it doesn't exist)

override_homedir = /home/%d/%u

'man sssd.conf' will give you all the options.

2.You can restrict this using an access provider option. I personally use the simple access provider to do exactly what you are describing

access_provider = simple
simple_allow_groups = user_group

Depending on your configuration you may want to use the ldap access provider, both are documented here:
http://docs.fedoraproject.org/en-US/Fedora/15/html/Deployment_Guide/chap-SSSD_User_Guide-Setting_Up_SSSD.html
8.2.3.2.3.1. The Simple Access Provider
8.2.3.2.3.2. The LDAP Access Provider

3.In an SSSD authentication configuration yes. I essentially create a minimal smb.conf for AD join and nothing else. I have asked about adcli inclusion in another thread (https://access.redhat.com/discussions/1119143), I personally don't use it because it isn't shipped with RHEL (EPEL only currently) so I still use the Samba method, no other real reason. Unfortunately this means you need to install samba packages to do the join.

thanks a lot PixelDrift.NET Support.Regards to IMU on 2012 R2. It looks like i was misreading. Title is:
RSAT: Identity management for Unix/NIS
The Server for Network Information Service (NIS) Tools option of Remote Server Administration Tools (RSAT) is deprecated. Use native LDAP, Samba Client, Kerberos, or non-Microsoft options.
http://technet.microsoft.com/en-us/library/dn303411.aspx
and the feature can be enabled via dism. They only deprecated the remote management tool i guess.

After reading your post regarding potential 2012R2 IMU deprecation (and several other posts that alluded to the same thing on other sites), I worked with a Windows Engineer and validated 2012R2 IMU functionality and have confirmed that it is still there and works as described from this Windows Server 2012 documentation:
http://technet.microsoft.com/en-au/library/cc731178.aspx#BKMK_command

The option that I believe is getting confused with the IMU functionality is the RSAT tools as you have mentioned. This displays deprecated in 2012R2, as below:

PS C:\Users\Administrator> Get-WindowsFeature -Name *nis*

Display Name                                            Name                       Install State
------------                                            ----                       -------------
                [ ] Server for NIS Tools [DEPRECATED]   RSAT-NIS                       Available

I have not used this feature as part of an IMU deployment.

Below is validation that the IMU steps still work as expected in 2012R2.

PS C:\Users\Administrator> dism /online /enable-feature:adminui

Deployment Image Servicing and Management tool
Version: 6.3.9600.17031

Image Version: 6.3.9600.17031

Enabling feature(s)
[==========================100.0%==========================]
The operation completed successfully.

PS C:\Users\Administrator> dism /online /enable-feature:nis

Deployment Image Servicing and Management tool
Version: 6.3.9600.17031

Image Version: 6.3.9600.17031

Enabling feature(s)
[==========================100.0%==========================]
The operation completed successfully.

From here the 'UNIX Attributes' tab was made available and UID/GID configuration for users/groups was enabled and validated. I don't enable the PasswordSync capability (from documentation) as I don't have a use for it, so I didn't test it.

I generally use AD groups. When using a directory I try and avoid local users/groups as much as possible.

You can specify sudoers groups using the standard '%group' notation, the only caveat being that the AD group must have a valid GID so that sudoers is 'aware' of it. With 'simple_allow_groups' in sssd.conf, the group doesn't necessarily need a valid GID as SSSD can access group information from AD about non 'unix' groups. As far as my experience goes (would love an alternative), sudoers is only aware of unix groups with a valid GID that are exposed to the system.

You can validate that a group is available with:

getent group adgroupname

A large amount of documentation when searching for sssd and sudoers refers to storing the sudoers rules in AD/LDAP, this isn't something I do personally. I prefer to manage the sudoers.d files with git and deploy using Puppet (or via RPM).

Once again this is down to personal preference, but there a several solutions when integrating your privileged access controls into AD groups (eg. you can potentially merge the function of the simple_allow_groups that provide access to the server, and the group that provides sudoers privileges).