KASLR and SMEP are kernel-mode protections, applying ASLR to kernel space and enforcing privilege ring boundaries on execution respectively. EMET is solely a user-space protection tool, and as such is not involved with KASLR or SMEP.
You should also be aware that EMET is not a magic bullet. It is designed with two goals: to raise the cost of exploit development, and to reduce or eliminate the efficacy of existing pre-written shellcode.
So, to answer your question regarding EMET and Windows 8.1, the answer is yes, there are plenty of protections that EMET offers:
SEHOP
SEHOP is a mechanism designed to prevent stack buffer overflow exploitation via SEH handler overwrites. EMET hooks the OS functionality which provides exception handling and inserts a check to ensure that the handler has not become corrupted, primarily by verifying that the handler address is one which came predefined in the application.
Dynamic DEP
Data Execution Prevention allows for hardware enforcement of execution access flags on memory pages. The normal configuration for an OS is to have DEP enabled for services, and then have applications opt-in based on a compiler flag (which is stored in the PE header, under the Characteristics field). EMET allows you to specify a policy that forces DEP on for a process, even if it wasn't compiled with this flag. It also has an additional benefit: it specifies the DEP policy for the process such that calls to SetProcessDEPPolicy from within the application cannot override this flag, so ROP chaining to that API won't disable DEP and allow for trivial stack execution.
Heapspray Protection
This protection is just designed to protect against stock shellcode pulled from frameworks like Metasploit. It pre-allocates common page addresses used in heap spray attacks and sets the memory to be inaccessible. This is useful because a lot of existing drive-by attacks use these addresses, and you can essentially prevent all of those attacks from working by allocating the pages they're looking for. Of course, someone who knows what they're doing can just re-write the shellcode, but it raises the bar to make it more difficult for script kiddies who only know how to use Metasploit or PoC scripts.
Null page allocation
Same as heapspray protection, except that it allocates a block of read-only memory at the null page address. The goal is to prevent null page dereferences from doing anything funky, though they freely admit that this is just a defense-in-depth measure as null page derefs aren't really exploitable bugs.
Mandatory ASLR
Like DEP, ASLR has to be compiled in with a flag, which again is set inside the PE header. The problem with ASLR is that even if your main program executable is marked as ASLR, it only has to load a single non-ASLR DLL into its memory space to result in a potential ASLR bypass - once there are known blocks of code in predictable locations, an attacker can build a ROP chain. Mandatory ASLR forces all loaded modules to be marked as ASLR-enabled, even if they're not compiled as such.
However, in Windows 8 (and 8.1) this feature does nothing if the native enforced ASLR implementation is enabled, because it does the same thing at the OS level.
Export Address Filtering
EAF monitors read operations on the Export Address Table (EAT) to ensure that reads are only coming from areas of application code, rather than shellcode. This is intended to make it difficult for shellcode to scan a module's EAT to find an API, where the module address is leaked in some way to facilitate such a trick. This is another mechanism where they use heuristics to guess whether the caller is shellcode or not, and isn't foolproof. It's just designed to catch out the low-hanging fruit.
EAF+
This is an extension of EAF, but it can be used in conjunction with or independent of EAF. It checks whether the stack pointer is within an allowed range, and whether the stack and frame pointers are mismatched. EMET 5.0 introduces a "valid modules" list for processes, and when it is populated EAF+ also detects if a read is to the EAT pointer for those modules, and monitors reads of the MZ and PE headers for the executable in memory to prevent EAT / IAT scanning.
Bottom-up Randomisation
Also known as bottom-up ASLR, this randomises the location of bottom-up allocations such as the stack and heaps. It's an additional countermeasure to ROP that just increases the amount of entropy in the layout.
Anti-ROP
This is a whole suite of protections that help prevent ROP from being successful. It monitors LoadLibrary calls to prevent loading DLLs from UNC paths, prevents memory protection APIs from making the stack executable, checks that APIs are properly called (i.e. with a CALL, not a RET), tries to follow back the call chain to check for ROP-like behaviour, and attempts to detect stack pivoting (incl. checking ESP / EBP against values stored in context snapshots used in certain APIs). All of these together create a headache for anyone trying to build a working ROP chain.
Attack Surface Reduction
ASR allows you to whitelist which DLLs an application is allowed to load. This is useful for a large number of reasons, including blocking malware from doing DLL injection, preventing unsafe plugins from loading (e.g. Flash), and stopping exploits from utilising LoadLibrary for nefarious purposes.
Advanced Anti-ROP
This feature adds more anti-ROP features. It hooks deeper functions, e.g. ntdll's memory allocation functions, so that it becomes more difficult to bypass the anti-ROP checks. It also tries to catch out shellcode that contains a copy of a function prolog, executes it, and then jumps past the real prolog to get to the real function, as a form of hook bypass. Finally, it bans the ntdll!LdrHotPatchRoutine function to prevent abuse of the hotpatch functionality.
Certificate Pinning
This isn't a mitigation in the same sense of the others, but it enforces certificates in IE so that they can't be easily replaced.
The point I'm trying to make, here, is that EMET has a whole host of protections which, when enabled in tandem, make the exploitation process significantly more difficult. EMET is not trying to prevent APTs and nation states from breaking stuff. They're trying to make it more expensive (in terms of time / money / skills) to build working exploits, so that it's less profitable for bad people to try. They're also rendering most shellcode which isn't specifically designed to avoid EMET inoperable, which is a large percentage of the market. It's absolutely worth enabling it.
With your concerns about stability with certain applications, you just have to work out compatibility with different protections. EMET 5.0 has reporting features which log detections, so you can go through and attempt to identify problems. Start with all the major protections enabled and turn others on or off as you go, until you reach a balance.
As for certificate pinning, it's largely browser specific. There are, of course, plugins for Firefox and Chrome that do this, though I've been underwhelmed by some. Certificate Patrol is popular, but I find it way too noisy to be useful - you just learn to click OK blindly. Chrome does have the --hsts-hosts command line option, which looks great, though you'll need to do some manual work to get it set up right. Firefox now pins several sites by default, as does Chrome, which means you're already protected to some extent. Unfortunately, it appears that there's no simple way to manage your own pinning across all browsers in your environment, and you'll have to do the manual work.
Sources:
