For the first query you will see different ordering if SQL Server uses an [allocation order scan][1].

So make sure the table is at least 64 pages in size and that the allocation order isn't the same as key order then run the query at read uncommitted isolation level. 

    CREATE TABLE T
    (
    X INT IDENTITY PRIMARY KEY,
    Y CHAR(4000)
    );
     
    INSERT INTO T
    SELECT TOP 100 'A'
    FROM master..spt_values;
     
    /* Cause page splits so key order and allocation order differ
       and leaves one row per page so table is now > 64 pages*/
    ALTER TABLE T ALTER COLUMN Y CHAR(4001);
     
    SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
    
    SELECT *
    FROM T;

The read uncommitted isn't required for the above in the case that a table lock is taken, there is a hint for that but a less obvious way would be to change the above table definition to


    CREATE TABLE T
    (
    X INT IDENTITY PRIMARY KEY WITH(allow_row_locks = off, allow_page_locks = off),
    Y CHAR(4000)
    );


For the second query you want a hash aggregate rather than a stream aggregate. You can force this with a query hint or less obviously with a plan guide but this is more likely to be chosen organically if there are relatively few distinct groups compared to the size of the table.


  [1]: https://blogs.msdn.microsoft.com/sqlserverstorageengine/2006/11/08/when-can-allocation-order-scans-be-used/