How to initial onchip_memory in modelsim post-simulation?

Yes, the Quartus II software will initialize the memory with your HEX file. If you change the HEX file, remember to run Update Memory Initialization File and re-run the Assembler to generate a new programming file (or re-run the EDA Netlist Writer to generate your VHO) . The ATOM models initialize from the mem_init parameters in order to mimic this behavior - if you don't Update Memory Initialization File, then you won't get updated initial contents in your memories.

Now for your questions:

How to ensure that onchip_memory has been initialed correctly during modelsim post-simulation?

Do you have a specific concern that the on-chip memory isn't initialized correctly? That would be a fairly significant bug in the software itself. In general, I give software the benefit of the doubt until there's no other explanation. If you're just being cautious or curious, I can understand. Even so, your time might be spent elsewhere, I think.

Is there any rule or datasheet can explain how name change before and after QuartusII Fitting operation?

Nope. Pin names are generally sacred, for obvious reasons. Register names often survive without transformation, unless packed into a macro block (RAM, DSP, I/O), merged with a duplicate, or retimed. RAM outputs are particularly troublesome because the actual names attached to the physical RAM blocks come from the inferred megafunctions and not the user source, and Quartus II has many different ways to implement a large RAM into the available RAM blocks. I would normally route the RAM output to a debug port on my design or make sure it fed a set of well-named registers with a Preserve attribute to prevent any compiler optimizations. You can also preserve combinational nets with the Keep attribute. Essentially, you tell the software that you care about a select number of names and it keeps them around for you.

BTW. how could SOPC Builder bring the signals listed above into modelsim wave window automatically?

That's a novel idea but I doubt enough users will ever clamor for this feature to make it a priority. I feel your pain. I've debugged plenty of post-fitting simulations in Modelsim and finding the signals you want can be a challenge. The astute use of Preserve and Keep are the best solutions in my toolbox.

Could you also guide me how to decide the time resolution during modelsim Post-simulation?

I think 1ps will be more than adequate. I believe some of the ATOM models use (or used) a 1ps delay to resolve race conditions that normally shouldn't occur if you simulate WITH delays. I imagine most delays in the SDF are more several hundred ps. Still, better to aim for a slower simulation that works than a faster simulation that doesn't. :)

Happy Simulating!