Custom table as the 'User account table' in account definitions

Yes, but why do you want to do this? What is your use-case?

This will result in a highly customized/complex solution, so be aware of this!

If you still want to do this then you are in luck.
There is a connecter project on GitHub that has custom tables with the account definition functionality.

https://www.oneidentity.com/community/identity-manager/f/forum/34611/open-source-servicenow-connector
From this, you can reverse-engineer what you need to configure.

Just as a outline (by no means complete):

On the custom account table add customizers:
- TSB.Customizer.TSBAccountDefLogic
- VI.Common.Customizer.AccountEventLogic

Add columns (without CCC_)
- AccountDisabled
- IdentityType
- UID_Person
- UID_TSBAccountDef
- UID_TSBBehavior
...

Custom instance table (UNSRootB alike):
- AccountToPersonMatchingRule
- NameSPaceManagedBy
- UID_TBSAccountDef
...

Custom process/script (customized copies of)
- TSB_UNSRootB_SearchandCreate_Person_PostSync
- TSB_UNSAccountB_Insert script: (script: TSB_PersonAuto_Mapping_UNSAccountB)

User interface:
- You will need to configure a completed target system interface in manager!!!

Unified namespace:
- Configure the new custom tables for the unified namespace

Hope this gives you some insight,
Niels

Thank you very much for the answer, it's good to know this possibility exists in case all other options turn out less feasible.

I am trying to figure out my options for structuring data for multiple different target systems of any type. If there ever was only a one target system of that type then just extending its respective tables according to the target system's requirements could work, but if there's more than one target system then that option becomes unattractive fast.

I guess I'll try experimenting with mapping references to secondary tables next in Synchronization Editor. I wonder if there happens to be any information available on performance of the various Synchronization Editor mapping methods as opposed to a simple attribute-to-attribute mapping?

What I normally do is the following the keep the system manageable just as you stated
The main design principle behind this is to keep to UNSB tables as OOTB as possible and move all the custom/fancy logic
to the custom tables. This of course has a side effect in that you need to configure a lot more stuff.
But it makes integrating, changing and troubleshooting target systems a lot easier.
Also working on multiple target systems with multiple colleges ;-)
And less change of messing up the hole system as opposed of doing it all in the UNSB tables.

Just an outline there are many more fine details you need to tackle.

create custom table for user objects: CCCTS1User
create custom table for group objects: CCCTS1Group
create custom table for assignment objects: CCCTS1UserInGroup

Create columns in these custom tables matching the naming and formatting convention of the target system (this can make your sync proj mappings easier).
Create templates on these columns to pull in and format the data using FK columns:
CCC_UID_UNSAccountB fk to UID_UNSAccountB (so you get email, firstname, lastname from person or unsaccountb)
CCC_UID_UNSGroupB fk to UID_UNSGroupB
CCC_UID_UNSRootB fk to UID_UNSRootB

Create Insert and Delete process on UNSAccountB, UNSGroupB to CCCTS1User, CCCTS1Group
Updating is done via the templates on the columns, so you don't need an Update process.
Create Assign and remove process on UNSAccountBInGroupB to CCCTS1UserInGroup

Create AdhocProjection processes on custom tables: Create, Read, Update, Delete user in target system for single provisioning

Create 2 sync projects:
One for the single provisioning and synchronisation CCCTS1User <-> API@Target system
One for synchronisation to the UNSB table: UNSAccountB <- CCCTS1User

P.s. this is what works for me in my environment.

Regards,
Niels

Thanks for the example! I suspect there is a good chance others may run into the same problem and will find this helpful too.