Electronic – High level vs low level motor control – acceleration and velocity profiles

First, there are several definitional errors in your assumptions:

1. No, there is no way to do away with a ESC entirely, since the majority of what the ESC is doing is taking the small signal from the receiver, and converting that into a much larger signal capable of actually powering the coils in the motor. Most motors require far more power then the micro controller can supply.
2. Even brushed motors actually require ESCs. A ESC is, at it's most basic, a specialized type of amplifier (brushless models require more local complexity). Maybe take a look at the wikipedia page on ESCs for more clarity.
3. Brushless ESCs actually know the rotor position and speed to quite a high degree of precision. The issue is that with typical "hobby" level ESCs, there is no way to access this information. Howerver, to properly commutate a brushless motor, the controller has to know "where" in the rotation the motor's rotor is, so it can determine which coil to energize.
4. When you say "Servo Motor", what exactly do you mean? Do you mean the little encapsulated "RC Model" servos? Those are not servo motors, but actually little self-contained servo systems. See the wikipedia definition of a servo-motor for more clarity.

So, in summary:

• can a servo (brushless dc) motor allow doing away with ESC?
  First, there is no such thing as a "brushless DC" motor. Motors are fundamentally AC devices. "DC" motors actually convert the DC power to AC internally, via the brushes. A brushless motor just replaces the internal brushes with solid-state electronics.
• does a servo motor accept control inputs such as "revolve at 100rpm"?
  No. A servo system can accept such control inputs, but it would do so with a motor, a ESC/motor-driver of some sort, a mechanism for reading motor speed back, and a microcontroller/circuit to control the input to the motor driver in response to readings from the tachometer/speed-measurement-interface.
• does a servo motor offer an output saying "i am at 80rpm now"?
  Again, no, but a servo system could offer such a interface.
• does a servo motor at 80rpm go to 81rpm faster if it is requested to revolve at 100rpm versus at 81rpm?
  This is somewhat dependent on the servo system's configuration, but most of the time, probably. A proper closed loop system has to account for the time it will take to stop changing velocity, which is within the time for the 80-81 rpm velocity, and not within the time for the 80-100 rpm velocity change.
  Think about it like a physical movement. If you run 10 feet and stop, would it take longer then running to 10 feet and continuing at full running speed? Yes, because you have to begin stopping before you arrive at the destination, as infinite acceleration and deceleration are physically impossible.
• the less precise questions implicit in the text above.
  Please clarify

Realistically, there are numerous limiting factors in the precision of a control system (like a PID-based control loop). Even if you have direct feedback of the rotation speed of a motor, the ability of the control loop to correct for errors in velocity is limited by the available torque, the rotor inertia, the bandwidth of the control electronics, and the precision of the measurement interface.

Further reading: http://en.wikipedia.org/wiki/Servomechanism

^{simulate this circuit – Schematic created using CircuitLab}

The block diagram is simplified industrial drive position control loop. For your app. you can ommit certain stages, you would neeed current controller PI and velocity controller PI. From your open loop trajectory planner you calculate the velocity according to your formula, then you give a velocity setpoint to the velocity controller.

^{simulate this circuit}

Now if you own a functional BLDC FOC kit, this should be no problem since the current loop and velocity is yet implemented. What you might add is the torque (current) feedforward. As you said \$M=J\alpha+M_{load}\$ we can anticipate the dynamic torque setpoint before the velocity lags the setpoint. So there is a torque feedforward path that forwards the torque setpoint "a priori". \$M_{ffwd}=J\alpha=\frac{d\omega}{dt}J;\; I_{ffwd}=M_{ffwd}*k_i;\; k_i[A/Nm]\$
\$I_{ffwd}=\frac{d\omega}{dt}J*k_i\$

Since the velocity loop "a posteriori" can't immediately follow the dynamic change in speed, there should be introduced a first order LP filter before the the velocity PI controller (it's ommited in the picture), to delay the action until there is a system response due to the feedforward loop action.

The other thing is a simple trajectory calculator, which calculates a ramp. This should be a recursive algorithm that increments the speed and checks limits each itteration loop. This part doesn't have any feedback from real speed or position, it just computes in open loop. It's all up to regulation loops to follow the speed setpoint.