Werden die Daten nicht von vorn herein im UTF-8 Format intern in der Datenbank gespeichert und je nach client_encoding ausgeliefert?

Nein. UTF-8 betriftt nur Zeichenketten, eine DB kann auch binäre Daten speichern, die keine Zeichenketten sind. Es ist eher so, daß alle Daten raw gespeichert werden.
Dafür ist UTF-8 oder nicht UTF-8 unerheblich. Außerdem beherrschen die DBs meistens viele Zeichensätze, nicht nur UTF-8. Das Client-Encoding hat Auswirkungen auf die interne Umcodierung vor, für und nach der Übertragung.
In der Kombination MySQL / PHP z.B. hängt es von einigen Faktoren ab, ob die Codierung die rauskommt auch die ist, die reinging. Die Datenbankengine (Server) hat quasi einen Zeichensatz, die logische Datenbank selbst einen Zeichensatz, die Tabelle und Felder auch. Die Verbindung vom DB-Serverdienst zum Client hat einen Zeichensatz und der Client hat auch einen Zeichensatz. Einige Einstellungen werden ausgehandelt, andere sind fix. Dazwischen wird ggf. hin- und hercodiert. Das entzieht sich teilweise dem Einfluß des Anwenders / Programmierers.
So kann es dann passieren, das ein schöner UTF-8-String als Gurkensalat zurückkommt.

Das Kommando von Sebastian sieht gut aus, kann aber auch schiefgehen.
Das funktioniert so aber nur, wenn Du mysql verwendest. Eine anderes DBMS könnte andere Befehle erwarten.
Ggf. hilft "set names utf8" (ohne Anführungszeichen), wenn die Shell nativ auf ISO läuft und die Umlautcodierung schief geht. Vermutlich wird der dump aber bereits ein entsprechendes Kommando haben, respektive die Angabe von --default-character-set regelt das in Deinem Sinne. Vor dem Dump die Tabellen prüfen und Zugriffe verhindern, sonst kann es zu Inkonsistenzen kommen. MySQL ist nicht automatisch transaktionssicher und ein Dump während das DBMS arbeitet, kann halbfertige Updates enthalten.

Werden die Daten nicht von vorn herein im UTF-8 Format intern in der Datenbank gespeichert und je nach client_encoding ausgeliefert?

Nein. UTF-8 betriftt nur Zeichenketten, eine DB kann auch binäre Daten speichern, die keine Zeichenketten sind. Es ist eher so, daß alle Daten raw gespeichert werden.
Dafür ist UTF-8 oder nicht UTF-8 unerheblich. Außerdem beherrschen die DBs meistens viele Zeichensätze, nicht nur UTF-8. Das Client-Encoding hat Auswirkungen auf die interne Umcodierung vor, für und nach der Übertragung.
In der Kombination MySQL / PHP z.B. hängt es von einigen Faktoren ab, ob die Codierung die rauskommt auch die ist, die reinging. Die Datenbank selbst einen Zeichensatz, die Tabelle und Felder auch. Die Verbindung vom DB-Serverdienst zum Client hat einen Zeichensatz und der Client hat auch einen Zeichensatz. Einige Einstellungen werden ausgehandelt, andere sind fix.
Dazwischen wird ggf. hin- und hercodiert. Das entzieht sich teilweise dem Einfluß des Anwenders / Programmierers.

Das Kommando von Sebastian sieht gut aus, kann aber auch schiefgehen.
Ggf. hilft "set names utf8" (ohne Anführungszeichen), wenn die Shell nativ auf ISO läuft und die Umlautcodierung schief geht. Vermutlich wird der dump aber bereits ein entsprechendes Kommando haben, damit der Server die Daten richtig interpretiert, respektive die Angabe von --default-character-set hat das dann schon abgefeiert.
Vor dem Dump die Tabellen prüfen und Zugriffe verhindern, sonst kann es zu inkonsistenzen kommen. MySQL ist nicht automatisch transaktionssicher.

Das funktioniert so aber nur, wenn Du mysql verwendest. Eine anderes DBMS könnte andere Befehle erwarten.