I can not talk about OTP, but OSRM works exactly that way, providing an .osm file where the routing will take place. Just have a look of the running instructions to getting a city up and running in 4 steps.
Regarding multimodal, OSRM supports "partially" multimodal routing. You can specify that by a so-called profile, which is the way of personalized OSRM, and, in summary, a file to describe what kind of intersections to consider and what is the cost to traverse them.
As an example, if you use the default profile provided (car.lua), the pedestrian streets will not be included in the routing graph. The costs of traversing the arcs is the travel time needed, taking into account parameters such as the type of the road, speed, and the length of the arc. Other provided profiles are foot and bicycle.
You can not have multiple profiles running at the same time, though. You will need several running instances to achieve that.
To label the arcs with your own Dijkstra cost function the profiles is the way to go. Another constraint you may have is that these costs can not be modified dynamically. Once you run OSRM, the input data is contracted to a smaller graph, so there is no way of modifying the arc costs other than re-run again OSRM with a different profile. If this suits you, OSRM has a extremely fast runtime performance, solving queries in milliseconds.
