Okay. I would like to start by saying, back in my day, when I was a web host, we did not have so many libraries, control panels, and what not to make a coders life easier. I do not know Node.js or Nginx since these things did not exist at the time. We had to write our code from soup to nuts. And you may need to think in these terms. Of course there are tools for you today, and you should use them, however, there is no one total solution for you short of a really expensive product so you will have to do some research. I will give you some insight based upon my experience and that will be from the perspective of Apache, Bind, MySQL, PERL, etc. however, I will not really reference these too closely if at all. It is just another perspective.
In the days when I was a web host, a customer would sign up and create an account. From there, the account would be made in a database where the base customer data and other meta-data could be stored. The user would be required to login. From there, the customer would enter specific information such as a domain name. In your case, it could how they want to be known as much like in your example. I assume that Java would be particularly useful here. You do not want to expose this code since it will expose business rules and vulnerabilities. I assume that your JS would write to a database and the database has triggers available. I also assume that your database trigger can use Java or other language externally. Most databases allow triggers to fire off external code. You will need to figure out what data elements you need especially before any configuration is made programmatically.
In my case, a domain name would be created while in your case, you are creating a sub-domain. I will discuss both so that you will be prepared.
Back in the day, it was required in order to be a SOA (statement of authority) for any domain that there be 2 DNS servers on 2 separate networks. While this is not required today, it is still a good idea. I used Network Solutions for 2 of my DNS servers, another network just as robust for 2 more DNS servers, and created a single DNS on my local network. My primary servers where one each of the pairs of DNS servers on the two networks. I created the domain SOA records on my local DNS that would "push" the records to the primary DNS of each network and the secondary DNSs would pull from the primaries. Sound complicated? It is not. I created the records on one local server that the public DNS servers would derive their records from. This made coding much easier.
The point of the last paragraph is that you should have access to reliable DNS servers. This should be hosted elsewhere and could be your registrar as long as there is an API or some tool that you can access with code. You NEVER want to host a domains SOA on a DNS that requires the domain name to be resolved. For example, ns1.example.com should NEVER be be the SOA for example.com. As well, you do not DNS on your web server. This is for security and performance reasons.
Since your domain is likely hosted somewhere, hopefully with your registrar, see if there is an API available. If not, look for a registrar or DNS host that can do this for you. This will allow you to dynamically create sub-domains. Domain names require propagating throughout the Internet, however, sub-domains do not. The exception would be where a telecom caches DNS data.
As a web host, we would have a primary server and a secondary server for the website itself. The reason for this is fail-over and load balancing. In your case, the more accounts you create, the more you will want fail-over load balancing. Web servers have a limit to how many accounts they can host, either a limit on how many configured sites or a limit as to performance. You will want to know what limits you will face. This may mean several servers even without fail-over and load balancing.
With Apache, creating a site is a simple process. Just programmatically create within the /sites-available/ directory a configuration file. With the domain name example.com you would create a file example.com.conf. With a sub-domain, you would create a file user.example.com.conf. You would programmatically write the configuration data you need within this file. From there, you would simply copy the file from /sites-available/ to /sites-enabled/ and restart the web server. As for Nginx, I could not tell you what you need, however, the process should be somewhat close to the same. You do want to consider that a restart is an outage and can potentially fail. This should be mitigated as much as possible, however, may be unavoidable.
There are a few ways to do this; direct file access, creating an API, or creating a cron style task that exists on each server that will create the configuration. I suggest a simple API.
Now you will have to do the reverse. Remember that you will not only need to delete accounts, DNS records, and sites on your web server, you will also need to confirm that your processes worked and that the sites function the best you can. The processes you use to create the accounts will be roughly the same processes you use to delete them. You simply have to reverse the business logic. Not tough. However, confirming that the sub-domains are available will depend on what other things you are doing. I cannot help you with this. However, you can use a simple HTTP fetch and see if you get what you expect. On the simple side, code should do this, however, wget can too.
You can use your database to check-off that the processes you expected to work have completed, have been confirmed, and can also manage dependencies. As well, you can use this to communicate back with the user. Spinny things may not be realistic, however, a status page should work okay.
One last thing. You will want to segment and isolate your servers as reasonably possible. If you are hosting these servers, this becomes more critically important since you will not have firewall and segmented networks to increase your level of security. Hosting is kinda like hanging your butt out the window. If you are going to hang your butt out the window, cover it. You will want to make sure you implement as much security and simplicity into your servers as possible. Do not expose your API, database, code, and processes. Isolate as much as you can and consult with an expert along the way.