Fpga Crossing signals between related clock domains
No, you don't have to worry about meta-stability, but you do need to make sure you constrain the clocks appropriately.  Many modern FPGA Static Timing Analysis (STA) tools have commands to help constrain related clocks.  

You didn't mention which vendor you're using.  For the sake of example, the process for Altera would be to specify a clock constraint on the 54MHz source clock as your normally would, and then use "create_generated_clock" for the slower clock as shown below.  

create_clock -name {clk} -period 18.518 [get_ports {clk}]
create_generated_clock -name {clk4} -source [get_ports {clk}] -divide-by 4 -master_clock {clk} [get_keepers {clk_div_4}]


Note that we did not specify the frequency for the slower clock.  We only told the STA tool that it is the frequency of the source clock divided by 4.  If you follow this approach the STA tool will properly account for the latencies of both the source and derived clocks.

To verify that things are working as you desire it's often helpful simply just to use the STA tool to report the timing between registers that cross the domain and see if the results match your expectations.  Again, not sure which vendor you're using but you'll probably want to look for commands like "report clock transfers" or "report clock tree".

As for whether or not your approach is a good one vs running everything off the 54MHz, that depends on the details of your design and there is no one right answer.  Either approach is acceptable in various situations.  For example, if you run the entire design at the higher frequency then you don't have to worry with clock crossings, but your code may be significantly more complicated because of pipelining, or the use of multi-cycle paths.  However, if it's a just a small portion of your design that you want to run on a slower clock then perhaps you'd be better off doing the extra work to pipeline it instead of dealing with the second clock domain.