How is the 2 Node Cluster Limit Enforced for SQL Server Standard Edition?
Of course licensing is a necessary part of Microsoft's business, so it is not surprising that the installation would enforce the limits that the purchaser is granted.  

Setting up a SQL Server Failover cluster for SQL Server 2012 (Standard as well as Enterprise editions) you must first:

Create a New SQL Server Failover Cluster (Setup)

Option 1: Integration Installation with Add Node (i.e. only 2 nodes permitted.)


Create and configure a single-node SQL Server failover cluster instance. ...
On each node to be added to the SQL Server failover cluster, run Setup with Add Node functionality to add that node.


A notice says: For more information on the different possible scenarios during Add Node operations, see Add or Remove Nodes in a SQL Server Failover Cluster (Setup)



Option 2: Advanced/Enterprise Installation

Add or Remove Nodes in a SQL Server Failover Cluster (Setup)

This option continues on to link to other pages that provide more detailed installation instructions for Advanced/Enterprise Installations. The warning is not explicitly called out for these installations. 

This suggests that (1) the Add or Remove Nodes process and (2) the license or, if you prefer, the Standard edition, provides the tools to protect both the purchaser and the provider by controlling, in this case, how many failover nodes can be installed.



Looking forward to SQL Server 2016 SP1 which will bring some good benefits on Standard Edition, by allowing many features to run on Standard.  But it will not allow for multi-node SQL Server failover cluster installations. 

Clarification: For SQL Server Standard Edition (from 2000-2016) the failover cluster can only support 2 nodes per instance.  If you are using SQL Server Enterprise Edition you can support more nodes both synchronous and asynchronous, the exact numbers depending on the release you are using.

True, it is also possible to install another instance of SQL Server, even a failover cluster, but it would not be part of the first cluster. And if this was installed on the same physical server, there would likely be some resource contention.

If you want a Third Server in your landscape you can install another server and implement log shipping from the active Cluster Node to the Third Server.  Since this has some latency issues the Third Server will not always be fully up-to-date with the data being shipped to it.