Shouldn't handling taps be done by a view controller?
No. The rating control is meant to be a self-contained unit. Think of a button or a slider: a button takes care of highlighting and unhighlighting itself in response to touches, and sends action messages to its target as the button changes state; a slider moves its thumb around as the touch moves, and sends action messages when its value changes. The rating control is the same.
If you put the code to handle basic user interaction in the view controller, then you'd need to put that same code in every view controller that used the ratings control. That doesn't promote reliability, maintainability, or ease of use. Since the ratings control should always behave the same way in response to the same touches, regardless of where it's used in an application, it makes sense to write that code once in the control.
Similarly, the "rating"...for this control is also stored with the view code. Shouldn't the rating be in a Model for this custom control?
Again, no. The control needs to remember the rating so that it knows how many stars to display each time it has to redraw itself. If the view had to fetch the rating from a model class for every redraw, that's a lot of unnecessary communication, and much worse, it creates a dependency between the view and the model.
In Apple's implementation of MVC, the view doesn't know anything about model classes, the model doesn't know anything about view classes, and controllers mediate between the two. When an app presents a "scene" or a collection of views, the view controller will get whatever information should be displayed, and configure the views that it manages. So the view controller in the sample app might find the rating value in the model and pass that rating to the rating control. There's no harm in the rating control remembering the value. If the user changes the rating, the control will send a message to its target, which will normally be the view controller, and the view controller can update the model. If some other interaction (like a tap on the "next record" button or whatever) causes the view controller to display some other information, it'll update its views as necessary with the appropriate model data.
You're right that the model is the place where the rating for a given record (or whatever is being displayed) should be stored, and the model is where the value comes from, but it's fine for the control to remember its value just as a slider remembers its value or a text view remembers its text.
Am I misunderstanding how this is all supposed to work?
I think you're just trying to understand it in terms of other MVC implementations, such as are often found in web frameworks. It's hard to put aside one's preconceptions and just look at how the model, view, and controller classes work in Apple's frameworks, but I can see that you're trying.
Or is it ok to have model, view, and controller in the same class together?
No, the whole point of the MVC paradigm is to help you figure out how to separate things into distinct roles. MVC (Apple's version, anyway) promotes flexibility and reusability by eliminating the dependencies between model and view classes. Your model classes shouldn't care how the data it contains will be presented to the user -- the interface could be Cocoa or Cocoa Touch, or a text only interface, or a web interface, and the model wouldn't have to change at all. Conversely, your views should know how to present the information they're given, but they shouldn't know or care where the information comes from or even what it really represents. For example, the "rating" property in your new control is really just a number that the user can set with a touch, and nothing in the control should depend on whether the number really represents a rating of something or some other quantity.
Update: I looked at the tutorial a few minutes ago, and you're right that
RatingControl does act like both a view and a controller, but it does so in different contexts. To the view controller,
RatingControl is just a view like any other. From the perspective of the buttons inside the control, though,
RatingControl is a bit like a controller in that it creates and manages them, and it's also the target of the buttons' actions.