tl;dr: no, there is no support for limit switches in ros_control, but I'd argue that it is also not something that should be there (as something like initialisation of a robot to me seems like a higher-level behaviour).
At the moment ros_control is mostly concerned with providing an efficient and re-usable way to setup a (relatively simple) controller architecture that is able to interface with a ROS node graph. Most (if not all) default controllers operate at the joint-space level, and the package can be said 'to live' at the (or at least very near to) Controller layer (in a 3T architecture, just an example).
It would make more sense to me to make something like initialisation a higher-level behaviour, perhaps part of a larger overall statemachine (again, just an example, there are others) that encodes the Executive part of your architecture. At start-up, your application then always passes through the initialisation (sub)states first, before accepting any other requests for execution of behaviours. That initialisation phase would then interact with ros_control to switch controllers to the appropriate types at the appropriate times, search for the limit switches and setup your encoders properly.
ros_control (and more specifically, the hardware_interface part of it) could perhaps be used to implement an interface to your limit switch hardware, similar to the joint_state_controller (which isn't a controller at all, it's a sensor interface, publishing JointState msgs). Whether that is something that makes sense depends on preference and how you've setup the rest of your system.
