Question isn't clear.  Add a user to do what?

K2 automatically gets users from a security provider, so there is no need to "add a user" to somehow enable them to use K2.

In our system when workitems are created they are not allocated to an AD user initially but instead to a logical team.  In K2 the team destination is represented by a K2SQL account rather than an AD user or group.

So if a new team is created a new K2SQL account is required to go with it.  I don't know how the existing records were added as I was not around when this was done.

Programmically, this sounds interesting...but tricky.

You might be able to come up with something that allows K2 to take over some of the work.  One thing that comes to mind is firing a stored procedure when a new SQL user is added.  Of which, you could tap into the identity.identity.

This might be possible via Linked server to act as an interface between SQL and K2.  I found some interesting info here: SQL Server – Active Directory Interactio

We do things in the opposite direction where we add a user to AD then have to populate SQL tables to support our antiquated accounting software.

This still doesn't make sense.  Do the existing "K2SQL" accounts use the K2 security label or some other label?

The K2 identity mechanism works by way of security providers that handle the interaction with the underlying user store.  The default user store is AD, but there are built-in providers for Azure AD, SharePoint, generic LDAP and SalesForce.  You can also roll your own for whatever backend you want (including SQL).  We have done this in our shop and it has worked well.  If you are trying to authenticate SQL accounts in K2, you should look into this.

Another alternative would be to switch to using K2 roles.  Membership can be managed via the API, and activities can be assigned to a role on the fly.  When a new team is created, just create the role in K2, assign teams, then you can start assigning them tasks.