How things are analyzed is up to the user. If you do something like the following(I'm typing from memory so the syntax may not be exact):
set enabled_regs [get_fanouts enable_reg]
set_multicycle_path -setup 2 -to $enabled_regs
set_multicycle_path -hold 1 -to $enabled_regs
In this case we've made a group of all registers fed by the enable and multicycled to them. Of course, if your enable is a toggling register that just feeds back on itself, then yes, you've multicycled that path. (I'm sure people have made that mistake, and I'm also sure the router will always use a short path on that feedback and it will always make timing anyway, but the constraint is incorrect and it's theoretically possibly something could go wrong.)
I've seen people limit the fanout, to only fniding registers where it feed the enable port. Examples are at:
http://www.altera.com/support/examples/timequest/exm-tq-clock-enable.html?gsa_pos=1&wt.oss_r=1&wt.oss=get_fanouts&gsa_pos=1&wt.oss_r=1&wt.oss=get_fanouts The only issue here is what if the enable feeds the D port for some reason. I've never seen that happen, but potentially a concern.
Another option is to do the original and then just overwrite the enable path:
set_multicycle_path -setup -from enable_reg -to enable_reg 1
set_multicycle_path -hold -from enable_reg -to enable_reg 0
Be sure to do a report_timing for both setup and hold on this path to make sure it is properly overwritten. But again, circuits are timed how the user specifies, so this case is really up to the user. (Another idea would be to have a toggle flip-flop feed another register. That second register is what is used for get_fanout, and since it doesn't feed back on itself, all of it's destinations would be correct.)