Hi,
The complexity of a state machine would be just as daunting and even more cumbersome without playmaker, regardless of your framework. Complex OOP or complex MVC are just as messy after a while and as your project grows in size...
Documentation and strict conventions are key here to keep your project sane regardless of the tech you are using.
Yes, it's a very good idea to use PlayMaker as a backbone for your logic and have the rest coded in a regular way.
since you are a coder already, make sure you create the proper set of custom actions to go with your scripts, don't use the Get/Set Properties or invoke actions as they are affecting performances and are only there for non coders to be able to achieve their logic without coding.
I suggest you first try to understand playmaker on its own before mixing it up straight away with your own scripts. make sure you fully grasp the few rules about what a PlayMaker FSM is, where the power lies and where the restrictions applies ( typically, you can have only one active state per fsm, that's something to take into account straight away in your design patterns).
Usually, you will end up with a series of custom actions to communicate with your scripts and inform about state entering, and exiting. your script will then be told to start and stop execution by these actions. Try to come up with a convention and likely a c# interface so that you only build these actions that can accept any of your scripts.
you could have only one action per state, that has a field for a gameobject, and on that gameobject, the action will search for a component with the specifiied interface and will communicate via that interface to tell the script to start and stop executing. your script should also be made aware of that action script so that it can possibly tell the action that the execution is done. Or your script could fire a playmaker global event, which would be ideal, because more fsm can react to that script activity.
Bye,
Jean