The problem with your example is that it is built on the HKEY_CURRENT_USER root, which isn't any specific user. Instead, that's an alias - a symbolic link - to a completely different area of the registry on a machine, and where that link goes depends on the user which is running the code at the time (the same is true of HKEY_CLASSES_ROOT).
The underlying physical registry structure (which is built out of a collection of files) can be seen a bit more clearly under HKEY_USERS, under which the system normally mounts the individual registry files that live in per-user account profiles. This list of profiles itself comes from the system-wide registry, under the HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList key.
Under this, users are identified by their Security ID's. For local users on a machine, this is the Security ID of the machine itself (the SID value that Ghost Walker or Sysprep changes for you) plus an extra number which is the account ID in the individual machine's account database. For domain accounts, this SID is one attached to the domain itself.
There are also a small number of SIDs that are "universal", and one of these is particularly important to what GSS does. On every Windows machine, there is a special user account called "LocalSystem" (or sometimes SYSTEM, depending on which piece of user interface you're looking at). This user account has exactly the same security ID everywhere, and what is important about it is that it has the ability to do absolutely anything to an individual machine - it's the Windows equivalent of the "root" user account in UNIX systems.
Now, Windows services that need this kind of power are not common, but the GSS management client is one of them - most of the things people ask the GSS client to do need that level of access, and the GSS client always runs under that special built-in account. The thing is that because there's no actual user with that account, for any script you run using GSS, it is run under GSS such that HKEY_CURRENT_USER is pointing at HKEY_USERS\S-1-5-18 - in other words that special account that no human can log in as, but which can do anything.
So, what you first really want to do here is figure out what you really want to have happen in terms of which user accounts on your target machines you actually want to be affected by this. This means understanding whether your users have local admin accounts, or domain accounts, and how many of them.
This will generally involve modifying multiple bits of the registry; for instance, HKEY_USERS\.DEFAULT which is the template that any new user accounts are built from, and registry paths for SIDs that start with S-1-5-21 as all real-human account SIDs tend to.
For most purposes, this is easiest to do by writing a simple Windows Script Host script that loops over those parts of the registry; the WMI Registry Scripting example shows this for simple things, and the StdRegProv WMI provider includes a method for looping over sub-keys, so scripting something to alter a number of accounts under the HKEY_USERS root is probably the easiest thing to do, and then you can deploy that through the GSS console.