You propose a hex editor which uses a virtual address space to map 5-bit sequences (fivelets?) across a range of bytes. It sounds hard to decode though. Would be better to do it in sets of five bytes, with the fifth byte containing the 5th bits for the nibble pairs in each. (or is this what you were considering?)
Dunno why but the way you say it sounds overly complicated.
Text data usually encodes data with one byte per character.
One byte has only 256 possible values, so Japanese games often (not always) use 2 bytes per character.
Some even use three bytes.
2 bytes means 65535 possible values.
Most retro Japanese games have around 650 kanji characters.
Recent ones have around 2800 kanji characters. The ones who put all possible characters have around 8000.
So 65535 is a bit of an overkill.
But it's far easier to just use 2 whole bytes for the job, and so most devs do just that.
But devs in the nineties who had big troubles fitting the text in a tiny ROM, disagreed about that.
So instead of using whole bytes (each byte being 8 bits), they'd encode each character on less than 8 bit multiples.
That's a simple compression.
Lagrange Point had less than 0x80 characters.
And those characters were two identical sets (like upper case and lower case).
So they used 6 bits per character.
Battle of Olympus only needed 26 English letters and a few control codes.
So they used 5 bits per character.
As Rotwang said in his tutorial linked here, that turd of a game for NES based on the Simpsons
used 4 bits (half a byte, also called "nibble") per character for the most needed letters,
and 8 bits (one byte) for the other letters.
This idea was improved and called the Huffman compression and is widely used but the character length in bits is variable and thus wouldn't interest us.
There's games using even 12 bits per character (Zelda Kagami no Triforce and Tengai Makyou Zero for example).
Some hex editors offer options to modify the "unit" from a byte (8 bit) to a nibble (4 bit) or a half word (16 bits/2 bytes) or a word (32 bits/4 bytes). But all of these are multiples of 8.
If these options were freely configurable so that a table using less than 8 bit values per character (be it 5, 6, 8, 10, 12..), it would help for a few games (I bet the main usefulness would be for stuff like the slightly more common 3-byte characters though).