I don't think there is a significantly more "code friendly" way; instead I'd say that the "design principles" are more critical than the code, for what you are doing here.
I believe that you are on the right track, but a few comments ...
What you say in (1) seems correct, assuming that the lengthening of the "enable" (your long_rd from your FSM) accounts for the length of the slow clock-period.
(also, someone might argue you only need two stages of re-synchronization in the slow-clock domain, but three is better for mission-critical designs if you can handle the added latency)
What you write in (2) is worded a bit unclear, but I think you are saying that you would make sure that the address-bus changes some "safe" number of cycles prior to when the enable signal is asserted, and after enable is de-asserted.
This also seems correct, but note that after you've actually placed the design physically, you also must ensure that the routing/buffering-delays do not somehow differ to extremely to cause too much skew between all signals crossing the clock boundary, or perhaps too much clock-skew at the receiving flops.
(however, this is only a practical concern for very fast clocking and long-routing situations, where even the slow clock is quite fast and you also have large skewing issues)
You might want to take a look at this paper:
http://www.sunburst-design.com/papers/CummingsSNUG2001SJ_AsyncClk.pdf
It covers and reinforces design principles of what you are doing, specifically sections 8.1 and 9.3.