Return combined DTO from async controller
Short answer would be yes. However you have a few other issues with the code shown.

There is no need for the Task.Run in the example TestMethod. 

public async Task&lt;CombinedDTO&gt; TestMethod(SummonerDTO summonerData, MatchListDto matchData) {
    return await Task.Run(() =&gt; {
        return new CombinedDTO {
            summoner = summonerData,
            matches = matchData 
        };
    });
}


For a simple object like your model there really is no need to throw that on to a new thread. The DTO can be constructed inline.

[HttpGet("[action]/{name}")]
public async Task&lt;CombinedDTO&gt; GetSummonerData(string name) {
    SummonerEndPoint endPoint = new SummonerEndPoint();
    SummonerDTO summonerData =  await endPoint.GetSummonerData(name);
    MatchesEndPoint endPoint2 = new MatchesEndPoint();
    MatchListDto matchesData =  await endPoint2.GetMatches(summonerData.accountId.ToString());
    return new CombinedDTO {
        summoner = summonerData,
        matches = matchData 
    };
}


With that out of the way, this code is ripe for refactoring.

Starting from the bottom RiotApiRequestBase should not constantly create and dispose of HttpClient as this can have adverse effects (socket exhaustion). 

public interface IRiotApiClient {
    Task&lt;HttpResponseMessage&gt; GetAsync(string url);
}

public class RiotApiClient : IRiotApiClient {
    static Lazy&lt;HttpClient&gt; client = new Lazy&lt;HttpClient&gt;(() =&gt; {
        //later this may be moved elsewhere 
        var client = new HttpClient();
        client.DefaultRequestHeaders.Add("X-Riot-Token", "Token");
        return client;
    });

    protected Task&lt;HttpResponseMessage&gt; GetAsync(string url) {
        return client.Value.GetAsync(url);
    }
}


Keep an instance for the lifetime of the application. Alternatively, if you are using a more recent version of .net core consider using IHttpClientFactory.

Note the abstraction of the client, it will come into play later on.

The response in MakeAsyncRequest is already going to be disposed by its using. No need to wrap it again in GetResponseContentAsync. This also breaks Single Responsibility Principle as GetResponseContentAsync has no business disposing of the response. 

Based on the abstraction of the client, that functionality can be refactored to extension methods.

public static class RiotApiClientExtensions {

    public static async Task&lt;TResult&gt; GetAsAsync&lt;TResult&gt;(this IRiotApiClient client, string url) {
        var data = await client.GetStringAsync(url);
        return JsonConvert.DeserializeObject&lt;TResult&gt;(data);
    }

    public static async Task&lt;string&gt; GetStringAsync(this IRiotApiClient client, string url) {
        using (var response = await client.GetAsync(url).ConfigureAwait(false)) {
            return await ReadContentAsStringAsync(response).ConfigureAwait(false);
        }
    }

    protected static async Task&lt;string&gt; ReadContentAsStringAsync(HttpResponseMessage response) {
        using (var content = response.Content) {
            return await content.ReadAsStringAsync().ConfigureAwait(false);
        }
    }
}


You appear to be following a format similar to CQRS (Command Query Responsibility Segregation), with your end points acting as queries.

I've used the following abstractions to help standardize queries. 

using System.Threading.Tasks;

public interface IAsyncFunction&lt;TResponse&gt; {
    Task&lt;TResponse&gt; ExecuteAsync();
}

public interface IAsyncFunction&lt;T, TResponse&gt; {
    Task&lt;TResponse&gt; ExecuteAsync(T parameter);
}

public interface IAsyncFunction&lt;T1, T2, TResponse&gt; {
    Task&lt;TResponse&gt; ExecuteAsync(T1 parameter1, T2 parameter2);
}

public interface IAsyncFunction&lt;T1, T2, T3, TResponse&gt; {
    Task&lt;TResponse&gt; ExecuteAsync(T1 parameter1, T2 parameter2, T3 parameter3);
}


A similar format could be used for Actions/Commands

Using the above, look at the transformation of SummonerEndPoint and MatchesEndPoint

public interface ISummonerEndPoint : IAsyncFunction&lt;string, SummonerDTO&gt; { }

public class SummonerEndPoint : ISummonerEndPoint {
    private readonly string baseUrl;
    private readonly IRiotApiClient client;

    public SummonerEndPoint(IRiotApiClient client) {
        this.client = client;
        baseUrl = @"https://eun1.api.riotgames.com/lol/summoner/v3/summoners/by-name/";
    }

    public Task&lt;SummonerDTO&gt; ExecuteAsync(string summonerName) {
        return client.GetAsAsync&lt;SummonerDTO&gt;(baseUrl + summonerName);
    }
}

public interface IMatchesEndPoint : IAsyncFunction&lt;string, MatchListDto&gt; { }

public class MatchesEndPoint : IMatchesEndPoint {
    private readonly string baseUrl;
    private readonly IRiotApiClient client;

    public MatchesEndPoint(IRiotApiClient client) {
        this.client = client;
        baseUrl = @"https://eun1.api.riotgames.com/lol/match/v3/matchlists/by-account/";
    }
    public Task&lt;MatchListDto&gt; ExecuteAsync(string accountId) {
        return client.GetAsAsync&lt;MatchListDto&gt;(baseUrl + accountId + "?beginIndex=0&amp;endIndex=10");
    }
}


Controller actions should be kept as lean as possible. It should really have only one purpose (SRP).

The initialization of the end points can now be inverted out of the controller and explicitly injected. This reduces the responsibilities of the controller and simplifies the action.

[Route("[controller]")]
public class MyController : Controller {
    private readonly IMatchesEndPoint getMatches;
    private readonly ISummonerEndPoint getSummonerData;

    public MyController(ISummonerEndPoint getSummonerData, IMatchesEndPoint getMatches) {
        this.getMatches = getMatches;
        this.getSummonerData = getSummonerData;
    }

    [HttpGet("[action]/{name}")]
    public async Task&lt;IActionResult&gt; GetSummonerData(string name) {
        SummonerDTO summonerData =  await getSummonerData.ExecuteAsync(name);
        MatchListDto matchesData =  await getMatches.ExecuteAsync(summonerData.accountId.ToString());
        var combinedDto = new {
            summoner = summonerData,
            matches = matchData 
        };
        return Ok(combinedDto);
    }
}


Ideally the controller could have been simplified even more with a service that encapsulates the combining of the DTO for reuse but that is totally up to you.

With that all abstractions and their implementations should be registered at the composition root on startup