What is the FrontEnd?
I looked for a documentation section that concisely defined what the Front End is but I did not find one therefore I shall attempt my own definition. I admit I have never considered this in detail nor dug into the low level connection between the Front End and Kernel, so this definition is bound to be incomplete and possibly incorrect.
The Front End is the entire GUI (graphical user interface) to Mathematica. It is the implementation of the Notebook Interface. The alternative is a text-based (command line) interface.
The Front End is responsible for accepting input from keyboard, mouse, etc. Typed input is converted into Box representation(1)(2)(3) that can be passed to the Kernel. Menu commands, mouse clicks, etc., perform operations that may be applied by the Front End itself or which invoke Kernel evaluation, or a combination of both.
The Front End renders Box forms, directly input or passed back from the Kernel, in a human bearable way. These range from the simple RowBox, SubscriptBox types to all graphics and dynamic expressions. (One may use the menu command Cell > Show Expression to see the box structure of any Notebook cell.) Syntax highlighting, spacing and line breaks are applied by the Front End.
Some Front End rendering requires interaction with the Kernel. In recent versions even FrameTicks may rely on Kernel evaluation so graphics may not display completely until a Kernel is started and definitions are loaded. Dynamic expressions have their own evaluation channel to the Kernel in parallel to the normal evaluation channel employed by Shift+Enter.
This answer is not meant to compete with @Mr.Wizard's answer, but to serve as a addendum presenting a historically-oriented view.
In the early days of Mathematica the dichotomy of front end and kernel was simple. Mathematica had a client-server architecture: The front end was the client and the kernel was the server.
The client's job was to manage the GUI, which could be broken into the following tasks:
- Get input from the user and typeset it on the screen.
- Translate input forms into kernel forms (think of these as FullForm) and send them to the server.
- Receive replies (evaluated forms and messages) from the server.
- Render the server replies on the screen (graphics rendering and more typesetting).
The server's job was to run the form evaluation engine on the forms received from the client and to return the resulting form (and perhaps some messages) when the evaluation reached a fixed point.
Since the introduction of Dynamic into the front end and support for parallel processing over multiple kernels this simple model has blurred, but perhaps it is still useful as a first-order approximation.