Fuel has an event handler (which is called Event). The core also triggers events you can hook into. Both are documented.
Fuel doesn't have a plugins system, it's a development framework, not a CMS or an eCommerce platform. If you want to do something specific in a core class, extend the core.
So you define an event by registering it. That gives it a name, and an action in the form of anything callable. You can register multiple callables to a single event.
Somewhere else in your code, you can call the event by triggering it, optionally passing data to it. This will call all defined callables (if any), and returns the result.
Where in your code you put these depends on what you want to do.
For example, we have an app in which the output system is event driven. The application is highly modular, and a call to a controller method processes a lot of different bits of code in different modules. All these code bits register themselfs to a theme event, for example "theme-sidebar".
When done, the theme template is rendered, that will trigger the "theme-sidebar" (and a lot of other) event, that calls all the registered methods to collect sidebar widgets, and that builds the page.
I already have you the link to a complete example.
It's not easy to give a simple example of an event-driven website, it requires a completely different architecture from MVC, which assumes one controller method == one web page.
Instead, it requires a frontprocessor (a single controller), that gets all requests, does a lookup somewhere which event handlers should be triggered, which template to use to geneate the page, and which (module) controller methods should be called when the events are triggered.
Usually, this works a bit similar to how some CMS system works. You install a "plugin" (in Fuel terms it will be a module), that registers it's event hooks, and an administrator has an interface to assign these hooks to pages in the website structure.