Yes. As Chicken Knife said, every monster on the list has its own pointer. 5B1F corresponds to DrakSlime, 5B29 corresponds to SpotSlime, etc. That's why changing a single pointer wasn't enough to change the whole list. And I suspect these pointers are only 2 bytes because the pointer table is in the same bank as the lists themselves.
However, where it's getting interesting is that I'm having mixed success corrupting the pointers to get results in the game. All of the successful name changes (TreeSlime, GoldSlime, and DragonKid) had pointer addresses beginning with 5B. So when I put them in the pointer table in place of DrakSlime (5B1F), the name was produced successfully.
The unsuccessful name changes (Herb, TERRY, Sidoh, etc) had pointer addresses whose bytes began with something other than 5B, which produced various jumbled results such as "e", and a blank name.
I went to the monster list and found the first monster that didn't have a pointer address beginning with 5B. This was LizardMan, whose pointer address was 5C00. So I replaced DrakSlime (5B1F) with LizardMan (5C00) and when I booted up the game DrakSlime was now called MARI... a name which I recognized from a list of 4-letter name suggestions.
MARI's pointer address is 5B00. So it appears as though the pointer table with all the 5B bytes is treating everything there as if it begins with 5B, and ignoring the 5B part of the pointer. It has to be pulling the big byte from another location in the data, I guess? Or is there still a 3rd byte that is also functioning as part of the pointer, but separate from the bulk of the pointer table? Not sure how to progress here, and any more help would be appreciated.