Your basically asking what the implications of breaking the MVC pattern are. You can write an application in anyway you want. However, the advantage of using a pattern like MVC is that it is widely known. Any programmer who understands MVC can look at your application and say "Yes, I understand how the data flows throughout your application and I can add features to this existing application." If you go off book and start using an unrecognized pattern then only you will know how it works. You will have to spend time training someone else to learn how to modify your code. Another downside is if you need help with your application, then your going to have to find someone who understands your code before they can help you.
If you've already written code using the MVC pattern, then you should continue to do so. Changing the method by which data is being passed around your application after you have begun writing it is a bad idea. The code will be confusing to anyone else and probably you after not working on it for a couple months.
If you are creating an instance of a controller class in your view, then you will need to test that. This may be a pain to test. I don't know how you are planning to use the controller once instantiated, but if your planning to do any logic in your view, then it will be difficult to test. There is a reason that the controller modifies the view and not the other way around. It's easier to test a controller than it is a view.
Those are some reasons why diverging from the MVC pattern and why creating a controller inside a view is a bad idea. I'm certain there are some good reasons to do it, but I'll let someone else explore those.