No, not through the rest API nor directly via scripting at present. It's very poorly documented at present because it's brand new to 8.3, but there is another possible solution to your issue; more on that later.
Correct, the entire many file based configuration storage is new to 8.3; prior versions used a SQLite "internal database" to store all configuration and we did not support editing that database directly.
For posterity, while you can do this, the address mapping feature is generally recommended against as an antipattern. While the ability to "know" which addresses you have when configuring tags later is nice, the added indirection only serves to make things more confusing when you're debugging. Further, it's a non-standard item that's Ignition specific instead of a more direct mapping of holding registers/etc that users of other SCADA/PLC software will probably find more readable.
There's an important distinction to pull out of this statement that will help you understand things.
When you create a device connection in Ignition, ~nothing happens other than a device connection being made. Devices (mostly; some have different protocols that require this) do not poll by themselves. It is the act of creating an OPC UA subscription or read, usually by creating an OPC tag, that actually tells Ignition's built in OPC UA server to issue a read call to a device.
That is, you can create a Modbus device connection, and whether populated with an address map or not, nothing is being read from your device until you create Ignition tags that consume those OPC UA addresses. It is the tags you create that use the tag group settings, and that in turn means that your Modbus device is being polled at whatever your tag group rates are, but until those tags are made nothing is being polled.
In other words: you cannot assign registers to a tag group.
You can give particular tags a tag group, and those tags in turn may be reading registers, which may sound like a distinction without a difference, but understanding that fundamental fact now will make things easier to understand down the road.
This isn't the worst goal, but part of using Ignition is going to be using the designer, and there's no reason to hamstring yourself now. In particular, "at scale" you're going to have a much easier time creating UDTs to make setup en-masse easier and less error prone, and there are tools like the multi-instance wizard built in to the Designer that just don't work without a GUI.
Run the gateway virtualized, but run the designer launcher "locally" on your Macbook.
For one, performance is going to be much better.
For another, that's how you should run things in production - you shouldn't run the designer on the local environment where Ignition is installed.
For a third thing, that's how you're going to end up running things when you're connected to 'real' systems - any number of gateways you connect to are going to end up being physically remote from your laptop so you're going to have to run the designer launcher somewhere to get connected.
If you're worried about it, while I'm obviously not a neutral party, Ignition's installed applications are good citizens and won't cause a bunch of annoyances across your system if they're installed 'natively' - you can happily install and uninstall them as regular OS applications at will.
All that said, like I said at the top it's not currently possible to create tag groups dynamically via the REST API or scripting.
But I'll posit that truly dynamic creation is probably not what you really need, and you could probably get by with creating a set of 'standard' tag groups for all your systems. The way to do that (immutably) in 8.3 is via the external resource collection.
In the installation directory, in the data/ folder, you'll see a series of folders in this directory:
data/config/resources/core/ignition/tag-group/
Each of those folders will correspond 1:1 with the 'realtime tag providers' defined on your system (probably just one named default/).
In that folder you'll see a folder for each tag group you have defined; by default Default/ and Default Historical/.
In each of these folders will be two files, config.json and resource.json. You'll notice config.json has all the settings for any particular tag group.
If you go up a few levels you'll also see a
data/config/resources/external/ folder.
Any Ignition resources you create in that external/ folder are guaranteed to be loaded by Ignition, and guaranteed not to be written back to by Ignition - they become immutable system configuration delivered by the filesystem. So if you're setting up a hundred gateways, and you've created Ignition resources in the external/ directory of each, you can guarantee those resources are available (and cannot be removed).
Also note that you can just create resources via the filesystem in core/ if you want "regular" resources that can be modified/removed via the designer.
"Creating" an Ignition resource via the filesystem is easy - just duplicate the folder structure, so that e.g.
data/config/resources/core/ignition/tag-group/default/Default/
Moves to
data/config/resources/external/ignition/tag-group/default/Default/
At that point, you can either hit the 'scan filesystem' button or restart your gateway, and we'll pick up those new resources.
Some more context on the way Ignition "resources" are built up via disparate files: