Lock-free bounded stack in C++11
The general push/pop logic of the stack looks fine. The memory management however is somewhat flawed:

Missing Destructor

From the perspective of the unique ptr, the stack doesn't contain Nodes, but uninitialized memory (effectively a char array). So at destruction of the stack object, it won't call the destructor of the individual nodes, which in turn won't call the destructor of value.

In order to correct that, one could write a destructor for stack that traverses the nodes and manually calls the destructor on them. 

Assignment into uninitialized variables  

node-&gt;value = std::forward&lt;U&gt;(data);


Upon construction, no actual nodes are created, but only properly aligned memory is reserved, on which you later call the assignment operator. I believe (although I'm not sure) this is OK if T is a POD, but if not, then (move) assigning values to them is definitively not allowed, because custom move assignment operators usually assume that this points to a valid, initialized object.

So in general, I see two possibilities: 


You default construct all nodes upon construction of the stack and destruct them when stack is destructed, in which case std::aligned_storage is unnecessary. One can just use an array of nodes and pass it to the unique_ptr. In this case you also don't need a destructor for stack. Obviously that only works with default constructable T's and makes only sense, if T doesn't hold any resources after it has been moved from.
You actually create and delete objects upon calls to push and pop, in which case you have to use placement new (new(&amp;node-&gt;value)T(std::forward&lt;U&gt;(data));) and manually call the destructor node-&gt;value.~T() (not delete &amp;node-&gt;value)


Padding
I just want to point out that aside from the false sharing between head and free_nodes, which is avoided via padding, any thread calling push or pop will access both variables anyway and afterwards you still have false sharing between the actual nodes.

Performance
This code contains a lot of micro optimizations, which might or might not be worth the effort if the code gets reused in different contexts (its definitively  not worth for handling a worker pool). However, I'd suggest, to write at least few small benchmarks to ensure that those optimizations are in fact improving and not hurting performance.

Also I want to repeat my warning from the comments that for some reason, VS2013 (and also 2015RT) seems to be unable to implement std::atomic&lt;head_t&gt; in a lock-free manner, in which case the whole structure is probably much slower than a normal stack with a mutex.