It is really an interesting task and I can say that it should work with VM. At least we have some differences in handling the variants, BUT maybe we have also to tricks a bit.
First it is important to understand how VM loads products. A typical product is splitted on 8 different tables. Additionally we have to load the customfields (1 table). Sounds a lot, but VM uses also a lot caching technics. Lets use some numbers.
Lets assume we show 100 products with 3 customfields each, we would get (8 + 3) * 100 = 1100 sql ops per view. That is a really big task :-) But we use sophisticated caching technics. This means we cache any sql loading products.
Usually a shopowner uses the same 3 customfields on each product, just with a different config and so our calculation would be for 100 products (in the ideal case, that we use always the same 3 customs, just differently configurated per product) 8 * 100 + 3 = 803.
So now lets assume a shopowner is using an unpublished parent product as pattern, which keeps two of the customfields already (the same for each product). We get 8 * * 100 + 8 +2 = 810. Sounds a bit more than the 803, but makes 100 sqls faster, because they deliver no result (DB just uses the index). A lot people think by experiences as yours that children products are bad for performance, but actually using product children makes VM faster!
I think this shows a bit how much you can do with a correct setup of the products. Now lets talk about the multivariant. The trick of the multivariant is, that it does NOT load all products, when go on the productdetail page, or when you browse it. The variants are stored in the customfield. So it just loads the parent, the child product and the other products just as simple dropdown (the information is "prerendered" when you store the parent product keeping the children).
So I think you see, it is possible in general, but you face other, different problems. When you are in the Backend, a normal browser just has problems to display a table with more than 800 rows. There comes the next problem (but simple to solve), I added an hardcoded limit of 700 prodcts per "getProducts" call. So actually you will get also trouble with VM to handle that many children with just multivariant,....
But a VM product can have up to 7 parents. So in your case, I suggest to combine the whole thing with the generic child variant. First create a parent, which keeps your first 10 options as generic child variant. Then add to these childs the multivariant.
Then it should work really smoothed. As explained above. It makes almost no difference if you display 20,50, or 100 variants with the MV, it loads always with the same time.