First off: "Lightning" is a larger (marketing) effort to rebrand existing and new Salesforce1 platform services under one shiny new umbrella. "Salesforce1 Lightning" consists of the following pieces, among others:
- Lightning Schema Builder (rebrand of Schema Builder)
- Lightning Process Builder (rebrand of Visual Workflow)
- Lightning Components (new - port of open source Aura Framework onto Salesforce1 platform)
- Lightning App Builder (new - drag and drop assembly of Lightning Components into a page)
- Lightning Connect (rebrand of "External Data Objects", which allows you to interact with external data sources that implement the OData spec as if they were regular Salesforce SObjects )
What you're asking about, though, is really Lightning Components (LC) and the Lightning App Builder (LAB).
As you've surmised, Lightning Components are essentially a rebranding of "Aura on the Platform" (AOTP), an initiative that's been going on within Salesforce for several years. Aura began as an internal initiative at Salesforce to build a scalable, component-based user interface framework, and earlier this year, Salesforce open-sourced the Aura Framework (available at http://documentation.auraframework.org/auradocs# and https://github.com/forcedotcom/aura). But as you mentioned, Salesforce1 is built using Aura Components, as are many newer components in various parts of the Salesforce UI (e.g. the Chatter Feed -- just Inspect Element on a page with the Chatter Feed or in the Service Cloud Console and you'll see Aura script libraries pulled in and attributes on elements).
Lightning Components are Aura Components --- if you go to create a new "Lightning Component", the actual markup you use is <aura:component>, and a lot of the core XML tags available from Aura, e.g. <aura:iteration>, <aura:if>, etc. are prefixed with aura and will remain that way.
Re #1) The goal of the Lightning App Builder, long term, yes, is to provide an admin-friendly way to construct apps by assembling and configuring Lightning Components.
Re #3) Lightning/Aura Components and Apps can currently be exposed in more places than just Salesforce1 --- and going forward (from what we've heard) more and more places where you can currently use Visualforce to "override" will be places you can use Lightning Components and Apps as well.
Lightning Applications are intended to be top-level, standalone entry points to distinct "apps". For example, Salesforce1 is a Lightning Application. Its Namespace Prefix is "one", and the App is called "one", thus it is available at /one/one.app , but Lightning Apps that you create can be accessed via the syntax /MY_NAMESPACE/MY_APP_NAME.app, e.g. in one of our orgs, our "Product Catalog" app is accessible via /sk_aura/ProductCatalogApp.app , and it looks something like this:
In general, Lightning Components are intended to be used to:
- extend / override portions of Salesforce's mobile (and eventually desktop) UI
- construct other Lightning Components
As of right now (Winter 15), Lightning Components can be used in the following specific ways:
Create Tabs within Desktop or Mobile Apps. To do this, a LC must implement the force:appHostable interface. Once an LC implements this interface, it can be chosen as the content of a "Lightning Component Tab", must like Visualforce Pages can be chosen as the content of Visualforce Tabs. Then, you can add Lightning Component Tabs, like any other Tabs, to custom/standard Apps / Consoles, as well as to Salesforce1 via the "Mobile Navigation" setup.
Override / extend portions of the Salesforce1 standard UI, via the "UI Plugins" framework. The UI Plugins framework exposes "Extension Points" where Lightning Components can be plugged-in to the standard UI. For instance, if your LC implements the force:recordTab interface, it can be added as an additional Tab / Slide within the SF1 record detail view by creating a new UiPlugin record from the Developer Console. It could look something like this:
