Yes, it is possible!
I don't have the time to go into all the details, but below is a starting point that covers how and what I understood from LuCI development myself.
LuCI is using the uhttpd web server, and consists in a set of (mostly) Lua files running on the router (there are also a few binaries and shell scripts), and also some Javascript that are run in the client browser for form field checking and Ajax partial page updates.
For its low-level layers, rather than tweaking directly with the different inconsistent interfaces for each admin task, LuCI is based on the OpenWrt UCI consistent config, thus its name 
Unfortunately, there is not much documentation on the subject, all that is available is located here:
http://luci.subsignal.org/trac/wiki/Documentation
I suggest you to start with the 4 first "reference" pages, then the 2 howtos on theme and modules. You won't require JSON-RPC, unless you are interested in providing Web services. And the development environment on the PC is pretty useless, since most of the values you will need are only available on the router itself.
Now for the LuCI structure: you write "applications", that may be grouped into "modules" (collections of applications", I would have done it the other way around, but...), using some libs, and applying translation (i18n) through some themes.
Each application can contain Lua source and C source, even if most applications only contain Lua.
Then each application may also contain 3 type sof objects, following the Model/View/Controller paradigm. This is the nice theory...
In practice, the "controller" is just Lua code (an "index()" function) that is called from the core LuCI dispatcher that receives HTTP requests from the client through the uhttpd CGI interface. This function defines a "map" of the URL to the things to do.
The "model" is just a big name for an API that converts a definition written in Lua to an HTML form automatically, and that binds the HTML form fields to corresponding UCI sections/options with validation. You can see this as an automatic UCI HTML form generation language in Lua.
Then "view" is just a collection of HTML templates that contains only a few Lua tags that are substituted to render the final HTML.
So generally, the index() function in the controller either calls a function in the controller to perform some operations, or create a model (automatic HTML<=>UCI binding), or apply a template from the view to fulfill the dispatched client's request.
Take the existing "admin-full" module as an example, then start to modify in it to understand what is going on without worrying too much for the packaging first.
Then once you are comfortable, you can try to create a separate application.
(Last edited by Squonk on 26 Nov 2012, 17:12)
