Ciao :)
parto dal rispondere alla tua ultima domanda:
Non sta di sicuro a me stabilire se il tuo è il (tuo appunto...) modo migliore di procedere, credo che ognuno abbia il suo e lo conosca bene, e se dopo oltre un decennio sei ancora in piedi e fai questo mestiere... beh forse hai già un buon metodo di procedere... L'unica cosa che mi sento di raccomandarti è di non fraintendermi quando ti dico che siccome provieni da asp questo si sposa bene, perché con questo non intendo dire che lavorerai veramente come con asp, dovrai comunque prima o poi staccarti da asp e dal suo modo di lavorare, intendo dire che (secondo me) questo ti da maggiore controllo sull'output come con asp (confrontato ad usare controlli lato server tipo datagrid ecc.), ma saranno due cose molto diverse.

La tua prima domanda in realtà ho dovuto leggerla più volte perché non capivo cosa esattamente mi stavi domandando, e sai perché?!? Perché non ero entrato in modalità "asp classic" :D sono almeno dieci anni che non programmo con il mio grande amico classic (io lo adorato!) e non mi veniva più naturale pensare in quel modo... ma vediamo se ho capito bene:
Dunque, in asp quando volevi visualizzare dei dati "freschi" andavi a chiamare ad esempio la pagina "clienti.asp", essa veniva elaborata dal server in base a dell'input (session; cookies; url; ecc..) ed in base a dei dati e funzioni che risiedevano sul server, il server restituiva una risposta in puro html, e qualche volta aggingeva javascript e/o comunque elementi html ecc. "roba client". Ovviamente ancora la rete gira in questo modo, ma l'attenzione si sta rivolgendo sempre di più alle possibilità del multi-piattaforma. Vista la natura dei nuovi device in commercio, ovvero quella della connessione in mobilità, e quindi la conseguente necessità di fornire a questi degli endpoint condivisi con altre piattaforme, è molto sentita, ne consegue che si rende necessaria una netta separazione tra quelli che sono i client, e ciò che devono fare i server. Quando dico "client" non necessariamente intendo browser.
Quindi anziché ragionare in termini client->server->client (in avanzamento), immagina più come un client<->server, ovvero uno scambio continuo di informazioni, ma senza "cambiare pagina" (quindi senza ricaricare il client o perlomeno senza farlo troppo spesso!) Cerco di spiegarmi meglio :
Sicuramente in asp ti sarà capitato di "riempire" una select con dei cicli nel server, dopo di che sputavi fuori html. Probabilmente se si trattava di una select che dava il via ad altre select (del tipo stato-regioni-città ecc.) non inviavi tutti i dati per tutte le select, ma immagino che usassi chiamare una pagina .asp tramite ajax con ad esempio la regione selezionata, ottenendo così tutte le città di detta regione nella seguente select. Bene vedila nello stesso modo, ma con una differenza: non chiami una pagina in background, ma chiami dei "metodi" che ti restituiscono qualcosa di simile a ciò che tu avresti restituito con una pagina.asp, ovviamente elaborandola allo stesso modo ed ottenendo l'input dell'utente tramite (anche) i parametri passati al metodo. Questi metodi possono stare anche dentro una unica pagina asp.net (come nel precedente esempio), ma è consigliabile creare una "classe" separata che li ospita, questo può essere fatto anche tramite la creazione di un servizio web, che a sua volta può essere di diversa natura, ad esempio WebApi o WCF ecc.
Per il momento facciamo solo dentro la stessa pagina aspx (o eventualmente anche in più pagine, ma...) senza usare WebAPI o simili, questo dovrebbe scaricarti un po da diversa roba, ma prima o poi dovrai vedere anche quelli.
Quindi ricapitolando: quando tu chiami GetMezzi(), è come se chiamassi citta.asp (come con la select) ma in background, quindi l'elaborazione "lato server" (diciamo il contenuto lato server della pagina.asp che avresti chiamato) la devi fare dentro il metodo GetMezzi() della pagina aspx, una volta elaborato devi restituire il risultato, ma lo fai sotto forma di lista di oggetti NET (la classe "Mezzo") che puoi generare come meglio credi. se ti dovesse servire avere dell'input dal client, come ad esempio scelte effettuate; filtri; ecc., li puoi passare come argomenti del metodo (ad esempio crei GetMezzo(string query), quindi accetta un parametro query e con quello esegui la query sul database). Dovresti prendere i dati dal database e per ogni "riga" da restituire dovresti generare un nuovo oggetto di tipo "Mezzo" le cui proprietà prenderanno il valore da ogni colonna che vuoi esporre (esempio targa; nome; ecc.), dopo metti tutto in un lista e restituisci al client chiamante (ricorda che tutto ciò avviene in background non chiamando davvero altre pagine), una volta li potrai elaborarli con jquery. Tutto questo lavoro di "creazione" del risultato da restituire lo potresti eliminare se usassi Entity Framework, ma qui ti dico anche io: "facciamo un passo alla volta". Ovviamente il lavoro della creazione dei controlli html senza associare (binding) i controlli stessi (tipo template) diventa enorme! ecco perché knockout (o comunque qualcosa che agevoli il lavoro come webform o MVC o simili), si tratta di evitare di fare anche gli aggiornamenti a mano... ah perché una cosa su cui dovresti lavorare (sempre immaginando la provenienza asp) è il concetto di stato diciamo "lato client", che sostanzialmente in asp non esisteva. In pratica parlo della possibilità da parte del client di mantenere uno stato dei dati che risiede solo li, ad esempio come nella select multipla: lo stato di quei dati esisterebbe solo a livello client se non fosse che il server ne viene a conoscenza quando richiedi la pagina asp per le successive select, ma prova ad immaginare se la richiesta partisse solo alla pressione di un bottone e non automaticamente alla selezione, in quel caso avresti uno stato sul client (che il server non conosce), ovvero lo stato delle select (cosa ho selezionato?). Ecco! incomincia a pensare di più ad uno stato client "perenne" (o quasi), dove le informazioni sono aggiornate in background con i risultati provenienti dai metodi come GetMezzi() (che ti ricordo sarebbero come la pagina.asp chiamata con ajax per aggiornare le select).
Quindi: creazione degli elementi del DOM dal client stesso, non sarà più il server a scrivere gli elementi html ma sarai tu (o knockout) a farlo, ecco perché hai il controllo assoluto! ed in base ai dati ricevuti tramite i metodi chiamati in backgroung (senza postBack con refresh di pagina) sul server potrai fare tutte le elaborazioni che vorrai, come ad esempio interfacciarti al database.

Per la seconda domanda: purtroppo non ho un esempio più specifico a portata di mano, ma se riesco te lo creo a breve. Dovrei più che altro adattarlo a te e non ho ancora inquadrato bene il tuo livello con NET e con jquery e html5 (quindi parlami per permettermi di aiutarti al meglio ;)). Quelli che ho al momento sottomano credo che sarebbero troppo complessi perché richiederebbero qualche nozione in più di quella che credo tu abbia in campo NET. Scusami per la franchezza, e se mi sarò sbagliato ti chiederò di nuovo scusa.

Per la terza: In alcuni casi ti do pienamente ragione, ma mi domando se veramente ne avresti voglia di creare davvero TUTTO a mano, può darsi di si, ma in quel caso sappi che dovrai comunque vedertela con il DOM e la sua creazione dinamica. E la cosa diventerebbe molto più pesante se solo pensassi che alcuni strumenti (come ad esempio knockout e/o brezee ecc., solo per citarne alcuni) fanno quello che faresti tu, e forse anche di più...
Ad esempio per sostituire questo :

dovresti dapprima controllare se esiste una selezione non nulla in una select, se questa non c'è dovresti inserire un valore di default, scrivere il valore nel campo, poi creare una sottoscrizione al dom per il cambio di valore, quando ciò avviene andare di nuovo a controllare se il valore è nullo, se non lo è allora scrivi il valore della selezione, diversamente scrivi "nessuno" ecc. e quando dico il valore in realtà intendo una classe, quindi fare tutto ciò su svariate proprietà, non solo sulla targa! senza contare ad esempio quanto dovresti scrivere per caricare di valori tutti gli elementi del DOM che compongono la pagina... a quel punto tanto vale stare su asp, fai meno ma sei molto più produttivo. comunque vedi tu, questo deve essere deciso anche in base anche alle tue conoscenze dei linguaggi lato client.
Oppure, se ti trovi meglio lato server, puoi incominciare a pensare ai metodi (come nell'esempio SetMezzo o GetMezzi) come se fossero le funzioni che chiami in asp, solo che li chiami quando servono, ad esempio anche se devi fare 2+2 sul client, puoi sempre chiamare in background il server predisponendo il metodo (ad esempio) int add(int a, int b) e far fare il calcolo a lui (il server), passandoli solo i parametri "a" e "b". Francamente ti sconsiglio di abusare del server, ma dipende anche da dove vuoi spostare il carico di lavoro.

Per il resto: figurati! ;)

Spero di non averti tediato troppo, e sopratutto di non averti offeso in qualche modo.

A presto.

Ciao,
prova a mettere qualche punto di interruzione per vedere dove si ferma e dove non passa. Inoltre ti consiglio di scaricare fiddler, sarà il tuo migliore amico in questa avventura, ti consente di vedere il traffico che transita dalla pagina al server, in questo modo potrei vedere se magari sbagli indirizzo o il contenuto della richiesta/risposta ecc. Infatti una delle prime cose che mi viene in mente come possibile causa del tuo problema e se stai indicando la pagina giusta, ovvero WebForm.aspx, diversamente allinea la richiesta ajax e il nome della pagina.
Diversamente ti passo un progettino funzionante, da li potrai anche andare un po "per differenze" e spiegazioni.

Ciao :)
domanda1:
La SPA non ha molto a che vedere con il lato server, infatti con SPA si indica Single Page Application, ovvero una applicazione in una singola pagina, diversamente dalla tradizionale applicazione (o sito) web che prevede diverse pagine, SPA prevede una singola pagina per qualsiasi cosa faccia l'applicazione. In pratica l'utente entra su una pagina senza lasciarla mai, e con il server si comunica tramite chiamate in background.
MVC è un pattern. In entrambe i casi lato server lavori sempre con .NET, quindi in teoria non fa differenza. Più che altro vedi diverse differenze tra i pattern quando li comprendi a pieno, li allora noterai che per fare una determinata cosa con un pattern può essere più semplice dell'altro, ma alla fine tutto si può fare con tutto e dipende molto dai gusti. Io uso sempre MVVM (no MVC) in quanto è l'unico pattern a sposarsi bene con qualsiasi piattaforma (vedi WPF,Windows Forms, Phone 8, Windows RT, SilverLigth, asp.net ecc.), infatti spesso uso condividere il 90 % di codice tra tutte le piattaforme.

Domanda2:
In realtà MVC non limita poi tanto, anzi devo dire che ti lascia abbastanza "libero", quanto meno confronto a WebForm (usato in maniera tradizionale con i suoi controlli, non con MVVM), quindi direi che non ha grandi limitazioni, magari continuando a leggere inquadrerai meglio il contesto.
Per eseguire query sul database esistono una miriade di tecniche, partendo lato server hai la possibilità di interrogare il db attraverso EF, ovvero un sistema che ti consente (anche) di non toccare per nulla SQL in quanto lavori con gli oggetti e lui pensa a interfacciarsi con il db in maniera trasparente, e puoi cambiare db semplicemente cambiando la connessione (passare tra SQL server, SQLCE, MySQL, Oracle ecc. senza modificare mezza riga di codice). Inoltre hai già gli oggetti che passerai al client. In pratica List<Qualcosa> lo ottieni già da EF, non devi chiamare il db e poi "trasformare" il risultato in una lista, questo lo fa già EF (Entity Framework), quindi potrai usare la sintassi Linq per eseguire le query, e a te apparirebbe come una "lista di liste". Per capirci :
database.Mezzi potrebbe essere la rappresentazione della tabella "Mezzi", poi hai che so :database.Utenti, ovvero lista di utenti ecc. se ci fosse una relazione 1-*, ovvero 1 utente molti mezzi, avresti una situazione del genere : database.Utenti.Where(w=>w.ID==MioID).Mezzi, in pratica così ottengo un utente specifico (w.ID==MioID) e quest'ultimo contiene una lista di mezzi che appartengono ad esso (quindi già filtrati). Mentre puoi decidere anche di esporre il tuo db (o meglio esporre solo quello che vuoi del db) tramite WebAPI (ad esempio), a quel punto (magari usando breeze) puoi fare le query dal client verso le WebAPI, queste esporranno tutte le liste complete provenienti dal db, ed in base alla query ricevuta restituiranno (automaticamente) i risultati richiesti. quindi in realtà in questo caso lato server fai ben poco, ti limiti ad esporre le liste che ti interessa esporre, poi sarà il server stesso in base alla query in arrivo dal client a "calcolare" il risultato. Riguardo questo punto troverai in rete informazioni utili cercando "OData".
Per quello che riguarda le operazioni CRUD in realtà basta organizzarsi, puoi farle in entrambe i casi, ma dovrai strutturare la tua applicazione in maniera corretta. In genere questo tipo di operazioni in MVVM viene gestito tramite una classe di base generica che espone i metodi necessari allo scopo, poi per ogni implementazione che richiede una sua specifica si sovrascrive (solo per quel contesto) il relativo metodo.
Ad esempio nel caso preso in esame (esempio del post) l'operazione di update può essere estesa anche a gli altri tipi (non solo Mezzo), ma più che altro in genere puoi avere i metodi specifici per ogni tipo (quindi uno per update, uno per add, remove ecc.) per ogni tipo che esponi (Mezzi o che so Utenti ecc.) mentre lato client ti crei quello che è definito il ViewModelBase con le chiamate alle operazioni, e poi per ogni tipo specifico puoi "caricare" il ViewModelBase ed aggiungere/sovrascrivere solo le operazioni che dovessero essere differenti dalla base.
Io mi sono creato un ViewModelBase (in javascript con l'ausilio di breeze) generico, infatti lo uso in questo modo :
var Mezzi = new Model("Mezzi", "Mezzo", manager, {}), specificando il nome del metodo sul server (Mezzi), il tipo (Mezzo), il manager che uso (breeze) ed un template del item in caso di aggiunta (in questo caso vuoto, tutti i valori saranno di default). Ora Mezzi possiede i metodi AddItem, RemoveItem, SelectedItem, GetItemsFromQuery, GetAllItems, Pagination (e relativi next, prev ecc.) più una marea di mezzi d'utilità che ho aggiunto nel corso del tempo, quindi faccio sempre una barra che chiama questi metodi (ovviamente in base alla pressione di un det. tasto), ma senza specificare su che tipo lavorare, infatti tutti i tipi (Utente Mezzi ecc) possiedono li stessi metodi che fanno sempre la stessa cosa indipendentemente dal tipo, ovvero fanno chiamate simili a ODATA senza preoccuparsi del resto. Nel caso su un tipo particolare debba fare qualcosa non prevista dal metodo di base, semplicemente lo sovrascrivo, ad esempio: Mezzi.GetAllItems = function(IDUtente){return Utenti.GetItemsFromQuery(...Una Query che filtra in base all'ID (da Breeze)...).Items;}.

In ogni caso credo di avere abbastanza elementi per farti un piccolo esempio di una applicazione reale (molto semplificata), ma sarà necessario usare Breeze + Knockout, quindi se vuoi incominciare dargli un occhiata sarebbe meglio.
Appena pronto lo posto, non so quando esattamente ma sicuramente in settimana.

Ciao alvaropetro,
inizio col rispondere alla tue ultime domande :
si,breeze serve per fare le richieste alle web api e per mantenere il contesto dati sul client, e in linea di massima è possibile non utilizzare .NET lato server, basta che il server restituisca ciò che si aspetta breeze secondo le sue convenzioni, poco importa cosa ci sia sotto il "cofano" lato server.
Riguardo la questione MVC è una questione di gusti, ma non solo, anche di "uniformità" con il proprio metodo di lavoro. infatti MVC e MVVM sono due pattern s molto conosciuti, ma con il primo in genere si lavora solo "lato web", mentre il secondo è utilizzato anche per tutto il resto, ad esempio WPF, Phone, Store; Silverligth ecc., quindi se lavori bene sugli gli strati del sistema puoi tranquillamente condividerli tra tutte le piattaforme. Con MVC questo diventa un po più difficoltoso. Il fatto che trovi più esempi con MVC è probabilmente una questione pratica, infatti raramente ho visto esempi che affrontano una condivisione di codice tra diverse piattaforme, anzi a dire il vero non è ho mai visti, ma non ne ho nemmeno mai cercati...

Ora passiamo al progettino d'esempio che ti ho promesso. Devi scusarmi se ti ho fatto aspettare è posto il tutto solo al termine della settimana, ma purtroppo è stata una settimana pesante, e quindi non ho avuto molto tempo.
Partiamo con la soluzione che potrai scaricare quihttps://onedrive.live.com/redir?resid=7545DD636BC09EB5!610&authkey=!AE2TIMjPRps5bkU&ithint=file%2czip
Una volta scaricato troverai dentro la soluzione 4 progetti :

Authentication : questo progetto è marginale, in teoria potresti anche non utilizzarlo, infatti questo si occupa solo della parte di autenticazione degli utenti sul sistema, è comunque un progetto a se che può essere inserito senza fare alcuna modifica al resto del codice, tranne per il fatto che ovviamente andrebbero tolte tutte le parti all'interno delle zone contrassegnate con "#region Authentication" e ovviamente gli attributi "[Authorize]" dalle web api, diversamente nessun utente sarà autorizzato a lavorare sui rispettivi dati.

Progetto Model :
Questo è quello che si occupa di "parlare" con il tuo database. Si tratta di Entity Framework" (Code First), al suo interno troverai la "struttura" che fungerà da database. In questo caso ho utilizzato 3 tabelle, la prima (utente) rappresenta appunto un utente, questo ha la proprietà Nome (ogni proprietà rappresenta una colonna nel database), Cognome e una lista di "messaggi" (una relazione 1>*, ovvero un ogni utente ha una lista di messaggi). Inoltre in questo caso ci sono anche delle proprietà che riguardano l'autenticazione, queste sono all'interno dei tag "#region autentication" è servono solo per quello (quindi potresti non usarle togliendo l'autentiocazione). Poi c'è la tabella Messaggi, questa è la tabella che conterrà appunto dei messaggi. In fine c'è la tabella "regole" (nome sul db, ma la classe si chiama Role), che serve esclusivamente all'autenticazione. Il nome nel db è dato dall'attributo posto sopra la classe.

Il progetto PortableAuthentication è un progetto "portabile" che funge da client per il servizio di autenticazione. Non è necessario scendere nei dettagli per il momento, è sufficiente sapere che se usi l'autenticazione su altre piattaforme (WPF, Phone Store ecc.) ti basta importare questo per lavorare in modo trasparente sul client. In questo caso inoltre c'è ma a te non servirà (potresti tranquillamente eliminarlo), infatti nel caso del web hai già un file js che fa il lavoro. (è rimasto solo perché la soluzione è parte di un progetto di esempio molto più vasto che ho semplificato per te, ma quando l'ho "uplodato" mi sono dimenticato di toglierlo). In ogni caso adesso non serve.

Ultimo il progetto Web.Entities, questo è quello che ci interessa principalmente. dentro trovi il file Authentication.cs che riguarda l'autenticazione (chiama il progetto Authentication), questo è molto semplice: si tratta di ereditare 2 classi indicando quale tipo sia il contesto (diciamo il database) e quale sia il tipo di user (in questo caso Utente), mentre per i role dovrai indicare la tabella Role (in realtà è già tutto sistemato, non devi far nulla li per il momento). Poi trovi il file ApiContext dentro la cartella ApiControllers, queste sono le webapi, e come potrai notare il suo contenuto è estremamente semplice, infatti ti basta esporre le "tabelle" del tuo database, ovviamente parliamo di Entity Framework, quindi esponiamo le classi del progetto "Model". Dentro la cartella App_Start troverai il file che mappa la route per il server, anche in questo caso non è necessari apportare modifiche (a meno che non vuoi cambiare la route!).
A questo punto la parte server è terminata.
Ora passiamo alla parte client che è quella che ci interessa di più. Tutti i file che ci interessano, ad eccezione delle pagine index.html e login.html, stanno nella cartella script, e nelle pagine suddette saranno importati tali file, quindi troverai il file Authentication.js che si occupa di gestire l'autenticazione, il file Model.js che si occupa di gestire anche le operazioni CRUD, la cartella plugin che contiene tutto ciò che riguarda ad esempio jquery, knockout, breeze ecc. insomma i classici plugin web. Prototype che ha degli script di utilità, e lo script HomeViewModel.js, quest'ultimo è il vero fulcro, infatti rappresenta ciò che dovrà fare l'applicazione, mentre tutto il precedente può rimanere così com'è, questo è quello che contiene la personalizzazione. Come potrai notare creo delle semplici variabili, alcune di queste sono di tipo "Model", e lo faccio passando il nome del tipo (es:Utente), queste contengono al loro interno tutti i metodi utili per le operazioni CRUD, ad esempio aggiunta; rimozione; ordinamento; paginazione; modifica; ecc.

In conclusione, tralasciando alcuni aspetti dell'implementazione possiamo dire che per creare la tua applicazione dovresti in primo luogo strutturare il database con Entity Framework come meglio credi, dopo esporlo tramite le webapi secondo ciò che ritieni opportuno esporre, e creare lato client le variabili di tipo "Model" (dal js) con i nomi delle tabelle che hai creato e metterle in binding con gli elementi html 5.

Ovviamente tutto ciò è abbastanza difficile da capire a primo impatto solo leggendo un post, per questo ti propongo di fare una breve sessione su skype (magari se mi fai avere un contatto) per poterti spiegare a voce il tutto. Sopratutto in previsione del fatto che avrai molte domande da pormi nei punti meno comprensibili per te.

Magari poi creo un modello per Visual studio da postare qui, in modo che anche gli altri utenti eventualmente interessati possano creare una applicazione semplicemente come si fa per MVC, quindi nella scelta del tipo di progetto sarà possibile scegliere questo e dedicarsi solo alla creazione del modello (database) e dell'interfaccia grafica.