You simply seem to not fully understand the MK64 architecture. You can’t directly access the FLexNVM. If the EEPROM emulation is enabled, the 128kB FLexNVM hide behind the 4K of FlexRAM. Reads and writes from and to the FlexRAM are then dispatched to the FLexNVM by the the memory controller and its wear leveling algorithm.
The reference manual states that the FlexRAM can be divided into 2 partitions, so that a part of the FlexRAM might serve for the EEPROM emulation and another part for other flash acceleration functions. But it states also clearly that the size of the EEPROM emulation can’t exceed the size of the FlexRAM which represents the transparent access door to the EEPROM emulation behind. Sorry, but it’s graved into the silicon and you should not complain here but at NXP.
Basically, the T3.5 data sheet and reference manual were available before you started your project, so you should have been aware of that limitation. Now, I wonder why you decided for the Teensy 3.5 and did even a custom PCB when your software specs don’t fit and you need more EEPROM than provided. It appears to me that something in your engineering process has gone horribly wrong. Normally, if you haven’t been aware of the EEPROM conflict in the design phase, you’d normally have stumbled latest during the prototyping, still with a “series” Teensy, before manufacturing your custom PCBs. Now that the hardware limitations are there, I’d rather consider optimizing my software to deal with the available EEPROM space, if I were you.
Perhaps some runtime-length-encoding could help decreasing the needed EEPROM size.