The system keychain is stored in /Library/Keychains/System.keychain and the key to unlock it is stored in /var/db/SystemKey (its default file permissions are readable by root only). The location of these files is referenced in the security-checksystem script (from the security_systemkeychain source). It is even possible to test to automatic locking/unlocking of the system keychain by using
systemkeychain -vt
The keychain security framework allows non-privileged programs to make requests for information provided they are in the ACL stored within the keychain entry. Obviously if a user has root they on a system they can directly access both the file storing the system keychain and the key to unlock it, thus they do not have make requests via the security framework and are not beholden to the ACLs stored within the keychain itself.
(I didn't actually answer the original questions so let's give this another go)
How are the keys architected such that any administrative user can unlock the System Keychain?
The libsecurity keychain framework allows regular processes to interact with the system keychain in an authenticated manner using Apple's XPC interprocess communication framework (IPC).
Program A sends a request to access the system keychain information using IPC. A check is made that the requesting user is already in the wheel group and also knows the password of a user in the wheel group. Once authorization is confirmed, the privileged kcproxy daemon can be used to access material in /var/db/SystemKey, unlock the system keychain and return the requested information.
Are there cryptographic restrictions that limit what an administrative user can do with information in the System Keychain in any way?
No - an administrative user is allowed to access/change anything in the system keychain. Even if they couldn't, they could copy the underlying files to another machine on which they have complete control and just unlock/access it there.
Given an unencrypted system backup without /Users, how would you gain access to the keys in the System Keychain?
If the backup contained copies of /Library/Keychains/System.keychain and /var/db/SystemKey then I would copy them to their respective locations on a new OS X system and use systemkeychain to make the later unlock the former and dump the keychain database using security dump-keychain.
I hate to reference unreleased software, but quite frankly the solution may be for you to enroll now in the iOS 9 public beta or simply wait for it's official Fall release. iOS 9 (at least in its current state) gives the option to set a custom alphanumeric password in place of the familiar 4-digit pin.
So, if you have hardware with touch ID capability you could use that for your everyday login and reserve a more complex passcode (even the same as your iCloud one, like you mention) for protecting your keychain in case of theft, etc.
Best Answer
In general "entangling" means that you're somehow "mixing" two components into one. This can be done in a number of ways.
In this specific instance what happens is that the UID and passcode are entangled by using an AES encryption algorithm. The UID is as the key for the AES encryption, and the passcode is used as the clear text. The cipher text is then the entangled data.
In order to create the entangled data, you'll need both the UID and the passcode.
The reason why this must happen on device is that the UID is a unique number that is "fused" into the CPU (i.e. each CPU has a different number, and it cannot be changed after the fact) - and that number is not accessible by software directly. However software can ask the CPU to encrypt data with the AES algorithm using the UID as the key - the software can then get the cipher text without ever knowing the UID.
As an added complexity, Apple actually uses a key derivation function known as PBKDF2 where additional computation is needed to go from the starting data to the actual data used as an encryption key. Apple is using 80 rounds (basically "loops" of a computation processes). The purpose of this is to make it slow (i.e. use a lot of CPU time) to come from a pass code (which we're trying to brute force) to the encryption key - even when you have access to the CPU with the UID inside it. Making it slow means that brute forcing takes a lot longer than otherwise, hopefully making it infeasible.