Simple: if the pointers are in RAM, they had to be written from somewhere. Set a write breakpoint to the locations and you should be able to find out where they're stored in the ROM.

Yeah, I realized that, but I wasn't sure of what it's called or what it is. What about $2000-$8000?

Incidently, I can't relocate the text to free space because the free space is swapped out for the two strings. I'm thinking my next best option is to disable a few control codes I don't have any use for, which are dakuten related, and making the game not recognize them so I can use them for a little extra space. I don't know how hard that would be, but I've made a little headway by possibly finding the place in RAM where the dakuten tile is stored/loaded, which is $06. I then found some related ASM and tried NOPing it, but it didn't break the game and didn't have any effect on the control codes.

Don't worry about trying to find the pointers.  You have enough room as it is.  When the dakuten are being called, the control codes used to call them aren't specific to the dakuten.  On the screen, it is being treated like any other character.

That being said, the control codes are pretty simple.  At the beginning of the string, one indicates when a string starts and the other indicates where it is being positioned on the screen.  For instance, the two bytes before the first dakuten are 21 6B.  If you change that 6B to 8B, you're now writing on the same line that the rest of the text appears on.  There are two more control codes and they are also simple.  FE denotes the end of the string and FD seems to be used just for the dakuten but does the same thing as FE. 

Knowing this, you could rewrite the page without the dakuten altogether.  This saves you space by only having to write to two lines instead of four, and the extra space which was used for the control codes and the dakuten is now yours.  You shouldn't need to mess with anything else.