KDE neon uses an Calamares installer, but it is not in Breeze style and doesn't follow the VDG HIG. I think we should adopt the common visual style in KDE Neon's Calamares. I think it should be as part of Breeze theme evolution T10891 and Goal: Consistency, to make it looks the same as a other KDE apps.
Considering that most Calamares devs are KDE devs (https://calamares.io/about/), it might make sense to see if they're interested in having the default look of Calamares changed. Even if they aren't, Calamares supports custom styling, so there's no need to make a fork of the installer.
https://github.com/calamares/calamares/blob/master/src/branding/README.md
https://github.com/calamares/calamares/wiki/Deploy-Guide#styling-calamares
https://github.com/calamares/calamares/wiki/Deploy-Configuration#how-to-integrate-calamares-with-the-used-system-style-and-theme
I think one of the goal of Calamares was to be distribution independent and DE independent (the universal installer). So I don't think using KDE design decision is a good idea, but making Calamares more themable would be cool ;)
Calamares needs to be run as root, unfortunately (so that it can mangle disks and write essentially arbitrary files in the target filesystem). That is usually done through pkexec or sudo. In both cases, you need to take care to preserve enough of the environment that Calamares can find the theming. I'm not sure if pkexec -E is sufficient. In any case, by pointing enough XDG things to the home directory of the live user, rather than root, you can improve theming without doing any work on / in Calamares itself. Not resetting $HOME might be enough.
A second thing to do is take a look at the branding setup. You can do a little with branding.desc, and a lot with QSS. I won't claim the entire thing is well-themable to within an arm's length of breeze, but you can go wild on the CSS styling. Most UI elements have spectific objectName set if you want to do special things. Use the Dump Widgets button in the debug dialog to find those names (makes me think maybe it should also print out class names for widgets, to help more generic styling).
The third place to look is the UI code itself. Much of it has accreted. I'm much obliged to @jensreuterberg for helping out there and pushing me to think about design issues -- even if progress is really slow on that front because my coding-on-the-UI time is limited. But if there are concrete suggestions for improving windows / dialogs / whatevers, I'm mostly ears. Bear in mind, though, that Calamares issue tracker is GitHub, and I read that all the time during Calamares-working days. Other issue trackers, not so much. A good mock-up -- and most Calamares pages are done in Qt Designer anyway -- will go a long way to change things. But: I won't accept things that are neon / Kubuntu / foo-specific. Calamares is a distro- and desktop-agnostic project, and must remain themable and adaptable to the needs of a wide variety of downstreams.
I just found this but I think the pictures showed while installation could be different.
like this for ex.:
As an update, prompted by @aronkvh 's comments: the actual KDE neon slideshow lives under https://invent.kde.org/neon/neon/calamares-settings , you'll need to find the slideshow.qmland patch that up with suitable QML, or go with an images-only slideshow which is easy to do (list of filenames in YAML) but suffers from scaling issues (although, TBH all of Calamares does).
Progress towards making Calamares "root"-less is very very slow.
Actually the code is at https://invent.kde.org/system/ubiquity-slideshow-neon (currently awkwardly ad-hoc converts html to qml because we needed to support both, a requirement that has gone away now)