I think it's a matter of preference. Depending on the type of game, the MVC architecture might be a good fit, sometimes/mostly it will feel out of place though. I have used it for puzzle games before (eg. your board is the model, the controller handles user input and makes the changes on the board and a view that renders these changes).
Another architecture that works well for game development is the component pattern. Your approach even goes into that direction, because you have a Player
object and add a Sprite
component added to it. Depending on the scale of your game and flexibility you need, you might even want to go further and have a basic Entity
class and components that define the entities look/behavior etc. And when you make this data-driven, then the real fun starts :)
Generally, I'd try to separate your game-logic as much as possible from your drawing API (in this case cocos2d). If you wanted to port your game to another platform/engine, then you'll have to separate all your code from the engine API anyway.
So instead of having a CCLayer
that instantiates your player, rather have some sort of Controller
that creates the CCLayer
and your entities and adds them to the layer.