Also, if you're doing something like MS's FlashMap (and I think they are) to reduce latency and access overhead (which they have said they've done), it's going to require an area of system ram used to store the translation table for the physical address of the data in question. And that's going to need to be part of the system reserved / protected ram for security purposes IMO.
IIRC the FlashMap paper gave a figure of 2GB of ram needed for a 1TB SSD. So there's probably a balance between SSD space accessible this way ("instantly available") and the amount of system reserved memory you want to allocate for this purpose. The balance MS have chosen probably equates to "more than 100GB". 100GB would be about 200MB, going by the FlashMap paper, but 1TB would require a huge 2GB chunk of reserved memory which would be unacceptable. So MS will have assessed the right kind of tradeoff to make between capacity and ram cost.
So I don't think the "more than 100GB" figure relates to any physical aspect of the hardware, or to a partition, or a separate SLC flash unit. I think it's about how software manages access to a particular part of a game's package on the SSD. The only limit would be the ram cost MS have decided is acceptable for facilitating the type of access described in their FlashMap research paper.
That's not to say you'd only be limited to "[whatever] more than 100GB". I expect you could still access additional data using whatever current systems are in place, much like back compat games will do. I doubt third party cross gen games will care about using DirectStorage or "Virtual Memory" at all, so I wouldn't expect to see seamlessly streaming games everywhere at first.
Edit: Link to the MS paper:
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/flashmap_isca2015.pdf
"
Applications can map data on SSDs into virtual memory totransparently scale beyond DRAM capacity, permitting themto leverage high SSD capacities with few code changes. Ob-taining good performance for memory-mapped SSD content,however, is hard because the virtual memory layer, the filesystem and the flash translation layer (FTL) perform addresstranslations, sanity and permission checks independently fromeach other. We introduce FlashMap, an SSD interface that isoptimized for memory-mapped SSD-files. FlashMap combinesall the address translations into page tables that are used toindex files and also to store the FTL-level mappings withoutaltering the guarantees of the file system or the FTL. It usesthe state in the OS memory manager and the page tables toperform sanity and permission checks respectively. By com-bining these layers, FlashMap reduces critical-path latencyand improves DRAM caching efficiency. We find that this in-creases performance for applications by up to 3.32x comparedto state-of-the-art SSD file-mapping mechanisms. Additionally,latency of SSD accesses reduces by up to 53.2%."