den perfekten Einstieg gibts nicht, sondern mehrere gute Möglichkeiten, aber auch mehrere schlechte.
Etwa mit den Plugins anzufangen, wenns noch garnix gibt zum dranpluggen ist glaub suboptimal.

Was ich günstig finde ist, kleinere Einheiten zu identifizieren, die aber trotzdem ein sichtbares Ergebnis liefern.
Weil imo kann man schlecht testen, wenn sich alles nur im Speicher abspielt und nix zu sehen ist.

Da kannste dann auch ruhig mal 'ne Woche mit zubringen, einfach nur eine Test-Oberfläche zu schreiben, allein dafür, zu testen, was du eiglich entwickeln willst.

Jo, soweit.
Also diese Einheiten sind iwie wie Kristallisationspunkte - die wachsen mit der Zeit, und mit noch mehr Zeit wachsen die auch zusammen.

Ach und immer aufmerksam bleiben, für wenn dir Infrastruktur-Code fehlt.
Also wenn du ieinen Dialog schreibst, und da kommt viel String-Verarbeitung vor, und du hast Ideen für ein paar nützliche Helferlein zur String-Verarbeitung - dann gib letzterem den Vorrang - mach also die String-Helpers fertig, und danach - mit deren Unterstützung - am Dialog weiter.
(Aber nicht andersrum - also nicht mitte String-Helpers anfangen, bevor du den Dialog anfängst - weil dann entwickelst du u.U. die dollsten Sachen - und brauchst sie inne Praxis nie-leben)

Ach, und viel Planen ist auch gut. Allerdings kann man sich auch tot-planen, ein gewisser Herr Clausewitz hat die bahnbrechende Entdeckung gemacht, dass sich Dinge oft (eigentlich immer) anders entwickeln als geplant. Und es gibt Dimensionen - wie "Zeit", "Detailiertheit", die dieses verflixte Eigenleben stark begünstigen.
Von daher empfiehlt er, nicht unbedingt bis in fernste Zukünfte und kleinste Details zu planen, sondern nicht weiter, als wie man auch (zumindest andeutungsweise) absehen kann.
Und dann auch mal anfangen, weil dann sieht man weiter (wortwörtlich).

Ich will jetzt hier keine Anleitung schreiben, sondern kann nur von meiner eigenen Erfahrung berichten.
Ich mache vorher gerne eine Aufwandsschätzung. Ich schreibe also auf, was alles genau gemacht werden muss und dann die Zeit die ich dafür brauche.

Zu der GUI würde ich mir am Anfang einen ungefähren Plan machen.
Aber auf keinen Fall die endgültige GUI am Anfang machen. Die kannst du am Ende immer noch ändern.

Persönlich mache ich es gerne, dass ich die GUI am Anfang simpel halte und dann später auf Funktionalität etc. anpasse.
(Das ist ja eine ganz eigene Kunst)

Außerdem würde ich empfehlen dir eine Managmentstrategie zu überlegen. S.h. z.B SCRUM
Scheint vielen als unnötig, kann mir aber keiner erzählen, dass er (oder das Team) ohne sowas schneller und effizienter ist.

Mein Arbeitsablauf sieht normalerweise folgendermaßen aus:
Erst schmeiße ich mir ein kleines Programm zusammen, welches die Hauptfeatures kann, aber keine ordentliche UI hat. Auch die Architektur des Codes muss noch nicht sonderlich gut sein, es ist jedoch ein guter Zeitpunkt, um schonmal eine performante Lösung für verschiedenste essentielle Vorgänge zu finden.

Von da an gibt es für mich zwei verschiedene Varianten: Wenn ein sehr gutes Interface das Hauptziel ist und ich mir schon im klaren bin, wie ich die restlichen Komponenten aufbauen werde, erstelle ich mir zuerst das UI und füttere es mit Testdaten, um die Funktionalität zu testen. Das Codebehind mache ich dann im Nachhinein, was meistens auch kein Problem darstellt.
Ist jedoch das Interface nicht ganz so wichtig bzw. ziemlich simpel aufzubauen, mache ich mich an eine ordentliche Architektur für den funktionellen Teil der Software und baue mir ein simples UI drum, welches für Testzwecke optimiert ist. Später kommt dann das "richtige" UI.

Es kommt aber auch darauf an, auf was du gerade "Bock" hast. Wenn du nach der Erstellung des Prototypen überhaupt keine Lust auf den funktionellen Teil hast, kannst du ja erst das UI und später das Codebehind machen.

Um dir aber genauere Tipps geben zu können, brauchen wir weitere Informationen - so können wir nichts zum Projekt passendes sagen.

Das, was du oben stehen hast, würde ich nicht als Projektstruktur bezeichnen. Core und GUI sind ohnehin in irgend einer Form immer dabei, dass du Pluginsupport haben willst ist lediglich ein sehr grober Wegweiser.
Von daher bist du noch an dem Punkt, an dem ich erstmal anfangen würde ein erstes Modell zu erstellen (es sei denn du hast bereits wesentlich mehr als im Eingangspost präsentiert).Es muss nichts endgültiges sein, aber es sollte dir genug Anhaltspunkte geben um mit dem Implementieren der groben Architektur anzufangen, du kannst und wirst dein Modell später noch anpassen, wenn dir Unzulänglichkeiten auffallen.
Für mich wäre dieses Modell ein Klassendiagramm und eventuelle relationale Diagramme, falls nötig. Wenn du keine IDE zu Verfügung hast, die sowas für dich darstellt, tuts auch Bleistift und Papier.

Und zum Thema GUI: Ästhetik ist zunächst absolut uninteressant. Wenn du zu Beginn keine schnelle und einfache Möglichkeit hast, deine GUI bereits in Ansätzen so zu beginnen, wie sie am Ende sein soll, dann ist das nicht schlimm.
Es ist allerdings extrem wichtig, dass du alle Daten, die dir zum Debugging nötig erscheinen, schnell einsehen kannst. Auch hier gilt, hast du keine IDE mit Debugging-Features tuts auch ne olle Console. Begehe nur nicht den Fehler, zu wenig anzuzeigen (tritt vor allem auf, wenn du so dicht kapselst, dass du an nichts mehr drankommst ohne deine Architektur komplett zu umgehen. Ist mir schon öfter passiert als mir lieb ist. ^^)

Wenn Neuland im Projekt enthalten ist, mache ich oft auch erstmal was ganz was anderes - nämlich Übungs-Projekte, bis ich den Eindruck hab, diese oder jene Technik so leidlich im Griff zu haben.
Zu die Widgets: Jo, kann man auch ein paar von machen, aber nicht zu viele, sondern dann auch mal zusehen, die tatsächlich zu integrieren, zumindest prinzipiell.

Also erstmal würde ich dann das komplette Plugin und Theming-System weg lassen und mit der Core-Funktionalität anfangen:
Mach dir erstmal eine abstrakte Architektur und wenn du dir 100%ig sicher bist, dass du alle gewünschten Features drin unterbringen kannst, kannst du anfangen, diese Features auch zu implementieren. Auch hier gilt: Erst mit den wichtigen Teilen anfangen, nicht essentielle Sachen kannst du immer noch später implementieren, wenn die Architektur von Anfang an passt.
Dann würde ich eine Schnittstelle für User Interfaces erstellen, über welche der UI-Programmteil alle denkbaren Aktionen abwickeln kann. Das würde ich bei solch einem Projekt möglichst abstrakt halten, damit du dich auch später noch beim UI-Typ umentscheiden kannst (z.B. Richtung GTK oä, wenn das mit Qt nicht hin haut). Dann hast du praktisch ein Layer, über welches du alle benötigten Daten aus der Core kriegst, welche aber nicht überladen ist. Dann würde ich das UI machen, jedoch auch hier alles möglichst abstrakt halten: Mach dir noch ein Workflow-Layer dazwischen, welches die Kommunikation zwischen dem Daten-Layer und dem UI regelt.

Nachtrag:
So ungefähr hätte ich die Architektur geregelt. Speziell würde ich darauf achten, dass jede einzelne Komponente ohne Änderungen an den anderen Teilen des Programms austauschbar sein sollte (Ausgenommen UI & UI Library, die gehören zusammen):

Ich kann dir auch nur SCRUM empfehlen, dein Projekt in einzelne Features zu splitten.
Diese Features werden dann weiter gesplittet, Backlog Items.
Diese führen zu einzelnen Tasks. Diese werden dann Sprints zugeordnet.

Grob anfangen und dann immer feiner werden. Klassen zum Beispiel erst mal grob planen und dann erst später richtig anlegen.

Also ich weiß nicht warum alle meinen sofort mit der Programmierung anfzufangen.
Du solltest bei großen Projekten erstmal alles durchplanen und dazu wäre z.B. das Wasserfallmodell interessant (Modell wie man sowas angeht, kannst du mal googlen)

Wasserfall Modell ist meiner Meinung nach für sowas überdimensioniert @RushDen.
Wenn dann etwas schmales, kleines und agiles. Aber auch da ist fraglich ob das wirklich Sinn für ein Ein-Mann Team macht.
Eine simple Todo-Liste mit grober Zeitplanung reicht hier wahrscheinlich aus. Denn mal ehrlich. Wenn du da SCRUM machst, was machste bei nem Daily-Scrum, ...

Für ein 1-Mann Projekt verfehlt das Projektmanagement wohl etwas das Ziel.
Aber was dir trotzdem eine Menge Arbeitszeit sparen würde, wäre UML.
Wenn du die Diagramme richtig anwendest, kommst du auf dem Papier vom Problem zur objektorientieren Lösung, ohne auch nur eine Zeile Code geschrieben zu haben und kannst Änderungen an den DIagrammen vornehmen, während sie bei Code einen größeren Aufwand erfordern.