I've been analyzing several RAM dumps and I thought I should share my findings:
The byte at offset 0x49526 corresponds with the size of your town tree. If you change the byte's value, the tree's size will update to reflect your change, but it will revert to what it should be next time you load the game. I'm fairly certain this is because it cross-references the values stored at offset 0x5C730 and 0x5C7BA when you load the game. 0x5C730 logs your total playtime (in seconds), and 0x5C7BA keeps track of how many days you've played.
In my RAM dump of my test town, there are 2 bytes from offset 0x5C730-0x5C731: 3B B6. Reversing the order (this has something to do with endianness if I'm not mistaken) of the bytes and then converting them to decimal leaves me with 46651 seconds. At offset 0x5C7BA is the byte 1F which is 31 in decimal. So I've played 31 days with nearly 13 hours of playtime. You need to have played 500 days and have 500 hours of playtime for a fully grown tree. Knowing that, I converted 1800000 (500 hours in seconds) to hex, reversed the order, and came up with 40 77 1B. I did the same for the days: converted 500 to hex, reversed the order, and came up with F4 01. I replaced the bytes from 0x5C730-0x5C732 with 40 77 1B, and the bytes from 0x5C7BA-0x5C7BB with F4 01. I then injected my edited RAM dump, and reloaded my game. The result:
Now, remember what I said about offset 0x49526? As you might've guessed, you don't have to change it at all. It will adjust itself to be in accordance with the values found at offset 0x5C730 and 0x5C7BA after saving, quitting, and reloading. For what it's worth, the byte at offset 0x49526 is 07 when fully grown, and 00 when at its smallest (00 also appears as a sapling for the duration of the first day in a newly created town).
(I time traveled to summer to take this screenshot)
I'm still pretty new to hex editing, so sorry if I didn't explain it well, or if I missed something.
Wow, this is great! Thank you!