Answer
Unfortunately, even though eMMC is a managed NAND solution (see the Knowledge Base article "Is there a way to add multiple gigabytes of storage to my EFR32 design?" for a discussion of managed NAND solutions), it is not an option for embedded devices like Blue Gecko.
Here's the story behind why this is the case:
Samsung developed one of several removable memory card standards in the early days of digital imaging called MultiMedia Card or MMC. In order to allow it to be used with embedded devices that did not have a dedicated hardware controller interface, Samsung added a SPI transfer mode that could be used in place of MMC's single clock, command, and data lines.
With digital imaging no longer a novelty, consumers began to pick winners and losers among the various memory card formats. As one of the early entrants in the market, SmartMedia (known formally as SSFDC for Solid State Floppy Disk Card), began to lose acceptance, its primary technology backer, Toshiba, got together with SanDisk and Panasonic to create the Secure Digital (SD) card standard. They essentially took the MMC standard, expanded the data bus to 4 bits, and added security features (essentially DRM for digital music) that were never really embraced by consumer electronics companies. Samsung responded by changing the name of the MMC standard to MMCplus, expanding the data bus to 4 or 8 bits, and increasing the clock frequency.
Looking back, the argument could be made that MMCplus was the superior memory card standard because it supported things not available in SD (at least at the time) like operation down to 1.8V. Additionally, when the need for physically smaller cards arose, MMCplus introduced the Reduced Size MMC (RS-MMC), an elegant form factor that essentially cut the vertical dimension of the card in half and added a physical extension as an adapter...

...as opposed to the kludgy MiniSD and its slide in adapter:

Of course, these mini versions didn't last very long, and both standards went to an entirely different, physically smaller format, with the SD Association taking ownership of SanDisk's TransFlash and making it their micro format:

As went the digital imaging market (and, by extension, mobile phones), so went memory cards. MMCplus never got the traction of SD, and Samsung ultimately turned the standard over to JEDEC. However, the story doesn't end here.
Samsung and other vendors, like SanDisk, had started working on what were essentially chip scale versions of their memory cards. These devices would come in packages with solder balls and were intended to be permanently attached to printed circuit boards.
Naturally, Samsung called theirs eMMC, for embedded MMC, and JEDEC, arguably, assumed ownership of the MMCplus standard really for the purpose of advancing eMMC and not the card formats. So, while SD dominated the memory card market, eMMC quietly began building a head of steam and ultimately became the de facto choice for high capacity on-board storage, driven by, surprise, surprise, the increasing difficulty of using raw NAND components and the impact it had on both SoC designs and operating system software (meaning the Linux kernel).
Mobile phone manufacturers, almost without exception, use eMMC for their on-board storage. The same applies to things like streaming TV boxes, car navigation and infotainment systems, and even super, low-cost notebooks and convertibles running Windows or Chrome OS (if they have 16 or 32 GB of storage, they use eMMC). Even SanDisk, whose iNAND embedded storage devices were at first SD cards in a chip package, ultimately moved to eMMC.
What, ultimately, does this have to do with using eMMC with EFM32, EFR32, and EZR32? Somewhere along the way as the eMMC standard evolved, maybe even in its first iteration, the least common denominator SPI transfer mode that was always supported by MMC was dropped. Without dedicated controller hardware (eMMC supports the original MMC 1-bit data bus in addition to the MMCplus 4- and 8-bit wide options), it's rather painful to interface an eMMC. Bit-banging is certainly possible if the dismal transfer rates can be tolerated because DMA is not an option as is the case when SPI is used with an SD card.
eMMC and why it is not a suitable microcontroller storage option