The question is very vague, but I'll try to give some ideas.
I don't think you correctly explain you idea. You say: "I don't want any mode coding in forms". It looks like you want to isolate UI from application-specific functionality, which would be the best thing to do. But in next sentence you say that you want to work with form controls in a separate classes. Yes, you can, but will it be a great improvement?
I feel that your problem with forms is not coding in form, but coding in the same files as forms. Think about it. And this is a good idea. Forms are contaminated with the auto-generated code. So, I have the following ideas for your consideration:
1) Keep working with form controls in form classes: there is where they belong. However, isolate your form-related code from the files created by Visual Studio from the template. Pay attention: form class is generated in two files, using partial class declaration. Created more files per form, one per a UI functional aspect. Pay attention: for partial declaration, you don't have to repeat inheritance list. This is very good: should you need to change base class, you will do it only in one file. Moreover, you can add interfaces to your separate partial declaration in a separate file. You can keep interface implementation in one file and separate it from others. Interfaces a good to communicate between forms. (From the other hand, avoid multiple forms; one main form is the best for application; use tabbing UI instead, or something similar) A file with a separate partial declaration per aspect.
2) Additionally (but not in replacement of the above), create classes working with form controls. This is actually your idea; I only want to make the following point: make them form agnostic. For example, population of control. If the population (more exactly, data-to-controls and controls-to-data) is complex, make a utility class for that. The class should know nothing about the form; it should receive a list of controls and work with them. There are many similar task which can be nicely isolated from a form. It will help to keep form clean.
3) Do not add any event handlers using Designer. Use it for layout only. Excessive auto-generated code is hard to support. Prefer manual code for handling event. Anyway, handling is not visual by its nature. Also, you can use anonymous delegates. The code generated by Designer is archaic, hard to support and even violates Microsoft naming conventions.
4) Do your best to isolate both application-specific and highly universal code (such as algorithms) from UI. Try to learn and analyze applicability of the following architectural design patterns: MVVM (
http://en.wikipedia.org/wiki/Model_View_ViewModel[
^]), MVC (
http://en.wikipedia.org/wiki/Model-view-controller[
^]) and MVP (
http://en.wikipedia.org/wiki/Model-view-presenter[
^]).
—SA