Linkedin do this for their mobile site (see http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-10-performance-tips-linkedin-mobile part 4), and it's apparently been very beneficial for them from a performance standpoint.
However, I'd suggest you avoid doing the same, for various reasons.
The first is maintainability: C#/ASP.net is, due to it being a server-side framework, client-independent, whereas Javascript is not (even with a framework like jQuery you're not going to get 100% cross-browser compatibility, not future-proofing). I'd say it's also easier to verify the functionality of a statically-typed application than an dynamic one, which is something you absolutely must consider if you're building large-scale sites.
The second is that you're going to find it difficult to find other people who are capable (and willing) to build a pure-javascript application of the kind of complexity needed to run your entire website (compared to the relative ease of finding .NET programmers). This might not be a concern of yours directly, but it certainly is something to think about from a long-term perspective.
The third issue is client-compatibility; if you're building public-facing websites then remember that a reasonable portion of the net still does not have JS enabled (for various reasons), so you'll need to be absolutely sure that you're not going to exclude a large portion of your userbase by switching to a JS-driven website.
As for your bulleted concerns:
I wouldn't worry too much about the security aspect, there's no reason why you could not mix paradigms and do some server-side processing when you require security (you're going o have some view-rendering code in there somewhere that returns HTML, there's no reason you can't have this just fire off an AJAX call instead, when required).
Ease of development isn't really a concern too, in my opinion, there are very good tools available for JS development, don't just box yourself into VisualStudio because you're used to it! (try JetBrains WebStorm, for example).
Performance of JS view engines is absolutely fine in most cases (again, in my experience), I use them heavily on a day-to-day basis. What I would suggest is avoiding the more heavyweight frameworks like knockout.js etc., and head instead for something like Jon Resig's micro template engine. This way you can plug in the supporting code in ways you're confident are fast and reliable.
What I'd do, if I were you, is really examine the reasons behind this switch; It could well be that you're just not leveraging .NET effectively and need to up your game, WebForms isn't a particularly slow framework out-of-the-box, so perhaps some of the 3rd-party libraries you're using are slowing down your rendering.
Try doing a performance profile of the application using a load test and profiling tool, and see where your bottlenecks are before you sink a large amount of time and effort into a more radical solution, you'll probably be surprised at what you find as the culprit for your slowness!
One tool that appears to do part of what you need, at least for Java webapps, is Web Resource Optimizer for Java (wro4j).
Free and Open Source Java project which brings together almost all the modern web tools: JsHint, CssLint, JsMin, Google Closure compressor, YUI Compressor, UglifyJs, Dojo Shrinksafe, Css Variables Support, JSON Compression, Less, Sass, CoffeeScript and much more. In the same time, the aim is to keep it as simple as possible and as extensible as possible in order to be easily adapted to application specific needs.
Easily improve your web application loading time. Keep project web resources (js & css) well organized, merge & minify them at run-time (using a simple filter) or build-time (using maven plugin) and has a dozen of features you may find useful when dealing with web resources.
You might also check into RequireJS to see if that would help you define which js files the client should download in a particular environment.
RequireJS is a JavaScript file and module loader. It is optimized for in-browser use, but it can be used in other JavaScript environments, like Rhino and Node. Using a modular script loader like RequireJS will improve the speed and quality of your code.
Best Answer
From your comments, it seems like you are at a very early conceptual stage, and want general guidance... well, that's going to be very difficult to give, since the entire topic is quite large. But in general, what you want to do is:
Well, that's at a very high level, and doesn't help us much. You can break down step 1 by reading up on the epub format itself (e.g.: wikipedia article and general info). Pretty quickly, you should notice that the format uses OCF to package together multiple files, so your first problem will be to create an OCF reader, which also means that you will need to be able to unzip the data in javascript (Florian Margaine's links should give you an idea of how others have solved this problem). At this point, I'd start looking for existing implementations in javascript, because you probably don't want to be implementing all of this from the ground up. This is all before we're even touching the actual contents of the epub file. Once you are past this point, you should be able to read in the actual contents, and attempt to translate them into HTML.
Regarding step 2, I'd start by looking at the various features provided by epub - text, CSS styling, embedded images, etc - and start attacking those one at a time, starting with whatever gives the most return for my time (probably text...).