The choice whether to write in C or Assembly (or any other languages, for that matter) is largely a personal preference. No matter what language you use, for OS development you will *always* need to have some assembly smattered around to access the hardware, so you can't escape it.
Generally, I would suggest using C for the large parts of your kernel, except sensitive parts where you absolutely must know exactly what the processor is doing, or for code that directly accesses hardware. If you have lots of skill/patience/time, assembly will usually yield tighter, more efficent, faster and smaller code, but at the expense of development time and your sanity
From the sounds of it (and I mean it in the nicest way possible -- we've all been there, I say that just now I'm escaping that stage), you are a newbie to OS development. If that is the case, I would definately recommend switching to C as early as possible.
My OS is almost entirely written in C. It's compiled to an ELF image that is bootable from GRUB. If I get the desire, I might wean the code off dependency on GRUB, but for the time being this setup works very well for me. I don't have to worry about bugs in the bootloader when debugging my code (I assume that GRUB is bug-free, which I think is a fairly safe assumption). That really helps development go quick at the start of the process.
One further suggestion: don't worry about a GUI for now. Yes, it's eye-candy. Yes, it's something people outside those that frequent this site will be interested in, but testing out the kernel functions from within a GUI causes all sorts of headaches. I don't plan on adding in support for a GUI for quite some time, at least until I have memory paging, a protected runtime, and loadable binary support (aka, executable "files", although my OS has no concept of files, but that's a whole other issue). That also implies that I'll have IDE support and a filesystem (although that's probably not a good name for it since it doesn't store files).
Good luck and happy coding.