You can click login, on the above link, and review the configuration process before buying the device.
I believe it should be possible to do the same with the LuCi code and possibly output an initial configuration. The configuration could then be copy/pasted into flash/ram challenged routers via ssh. This could be an external web site, or better yet, downloaded to a client computer so encryptation keys/PPPoE settings. remain private.
As usual in opensource, the difficulty and bottleneck lies in the implementation. Someone, and at this point that someone will be you, will have to give it a go, only then the feasibility will become obvious (I very much doubt you'll save any flash space though, and RAM remains an issue on 4/32 even without luci as well).
--
I've given some warnings about something like this not being as trivial as you make it sound on the topic of android/ iOS configuration 'apps' not too long ago, similar issues arise here - you cannot outsource input validation to an external application, unless you accept being in deep …problems whenever server- and client side implementations get only slightly out of sync. Likewise you'll have to cover parsing of existing configuration somehow - and suddenly it becomes a lot less trivial as you paint it to be.
My understanding is that LuCI is essentially an application of convenience and that it already parses and validates the code.
My brief experience building my own OpenWrt images gave me the sense LuCi is consistent across releases - not sure about targets though. Plus the project already builds release/target specific image generators, with package feeds, that must be way more complex than outputing /etc/config files.
If I put time into this, are others willing to help? If code gets veted and works, would the project host?
While LuCI is "just" a web interface to the underlying configuration, it is a two-way street. Not only does it set options, it also receives the options available for a particular device. And the configuration options vary wildly between devices, because the hardware differs wildly between devices.
So in effect one would have have to create a plethora of device specific -- and even OpenWrt version specific -- variants of that "offline configurator", and keep them updated as the options for these devices change (which they do, not often, but they do.)
And in the end, even if you could create an "offline configuration" to insert ... you would still have to SSH/SCP into the device to insert it. At which point you could just as well SSH/SCP into the device and change the configuration there. And fter all the work, the whole exercise results in just barely more concrete configuration examples than those in the documentation.
I belive it could be done in a way or another, but I imagine it would require radical changes. Now considering the fact that 4/32 devices are the past not the future (yes, I know some manufacturers still make entry level devices with such specs, but better devices are becoming affordable and not much different in price). So it's probably not worth the effort now, and very unlikely to be worth the effort in the future.
If luci used ubus only to communicate with the rest of the system then it would be easy to run it remotely since it uses a socket that you potentially can forward.