this is possible to build with CUBA, but multitenancy only plays a small part in it.
Normally what you need is some representation of Customers, Subscriptions, Plans, and Options as first-class citizens in the application. Based on that you can come up with dynamic roles to show particular parts of the application.
I did a PoC a while back where I integrated a CUBA app with Chargebee, which is a SaaS Subscription Management solution. Information about subscriptions are mirrored from Chargebee to CUBA and then persisted.
You can find it here: https://github.com/mariodavid/cuba-component-saas-management
Note: it is not a fully working solution, it was just a PoC. It is not even a complete add-on that you can use as-is. But you can take a look at the sources to get an idea.
You can use it with Chargebee but it will also work standalone. Based on the Limits that you associate to product plans, the application will only allow the user to do the corresponding actions or have capability limits like max. amount of entities.
Regarding the modules:
This depends highly on how you want to deploy your application. It can either be that you deploy different applications based on the tier that you offer. In this case, regular CUBA addons would work. If you have it in one running application, then you probably need something more dynamic that is based on permissions & roles. The above example is going more in this direction.
For Jmix, I’m not aware that there are any particular benefits coming from Jmix itself. Surely there is a better ecosystem factor to it with Spring Boot. This will ease your deployment story probably. So yes, there are certain benefits, but there are also downsides when it comes to the majority of the overall ecosystem. Most likely it depends on your time-to-market, required add-ons, developer knowledge, etc. if you should use Jmix directly, or start with CUBA and migrate to Jmix at a later stage.