As you've found, the instanceType attribute is marked "system-only", since you could potentially mess with the replication state of the directory replica in which you modify this attribute.

You probably shouldn't be doing this!

To circumvent this protection, add the following registry value on a Domain Controller:

Key:   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Name:  "Allow System Only Change"
Type:  DWORD
Value: 0x1

You could use PowerShell for this:

Set-ItemProperty HKLM:\System\CurrentControlSet\Services\NTDS\Parameters -Name "Allow System Only Change" -Value 1

Now you can modify the value of instanceType attributes on that DC. Either connect to that specific DC with LDP.exe/dsa.msc, or use the -Server parameter with the Active Directory module cmdlets.

Remember to remove the registry key after making your changes.

In my experience, there are two ways I've seen it done.

1. Purchase a solution that does what you need out of the box and becomes your identity management solution sitting on top of AD.
2. Write your own.

I will refrain from posting product recommendations for option 1 because it's against the site rules and I'm sure you can do your own research on that. But let me describe how we do it in my current environment with self-written tools.

The basic premise is that you should stop creating accounts by hand and let your tools do the work for you. Particularly with tools you write, you can hard code and enforce business rules about your specific environment (user locations, name formats, automatic group memberships, etc) that other tools can't possibly know about. That has the side effect of making your tools much easier to use. And the less you have people creating users manually from ADUC, the more consistent and reliable your environment becomes.

In our environment, all new identities associated with people are automatically provisioned (and deprovisioned) by an upstream, HR owned system. But this only takes care of the basic GAL-related metadata (name, email, phone, etc). We also have a powershell script running on the PDC emulator DC that runs every 5 minutes looking for accounts with incomplete RFC2307 profiles and updates them as necessary. It also updates GIDs for certain subsets of groups. UIDs and GIDs are generated based on an algorithm that calculates them from the account's SID. It could be possible for the HR system to provision the RFC2307 profiles as well, but at the time it was less work to have the AD team own that data/process.

Additionally, we have a home grown web page for provisioning "non-people" accounts like service accounts, shared accounts, test accounts, etc. Each type of account is automatically configured with appropriate RFC2307 attributes in addition to things like fine-grained password policies, username format conventions, etc.

At the end of the day, AD is just a giant LDAP server and there are many ways to interact with it programmatically.