My thoughts is that MMU as MPU works for isolation, but the sort of things FreeRTOS is built for don’t need the address translation ability of an MMU. “real-time” tasks need to be locked into memory as “swapping” defeats the ability to make real-time requirements.
I suspect that trying to add the ability to support a MMU for some non-real-time tasks in the system will just add overhead to the operations that the real-time tasks would be using.
There may be enough space above the space currently occupied by FreeRTOS and below the “real-time Linux” versions, for another product, It likely is enough different from the current FreeRTOS to make it not viable as a “fork” of FreeRTOS. You might be able to make a light-weight virtual memory OS that uses something based on FreeRTOS as a subsystem to handle real-time tasks, all in one common MMU configuration, with other non-real-time tasks as FreeRTOS “idle” priority that switch to other MMU configurations (likely with 1:1 address mapping) that access the FreeRTOS structures through wrappers that handle the MMU issues.